Здравствуйте, IT, Вы писали:

IT>которых в BLT нет. Пока.
Нужно ли?

Здравствуйте, olegkr, Вы писали:

IT>>которых в BLT нет. Пока.
O>Нужно ли?

Смотря как сделать. Так как это сделано в тяжёлых ORM, т.е. гвоздями прибито к мапперу, то точно не нужно. Если же сделать заменяемый DataContext, то вай бы и нот. Сейчас это только DbManager, но в планах уже Linq to Middleware, есть мысли насчёт SQL grabber, можно добавить и Entity Service или какие-то его элементы.

Здравствуйте, IT, Вы писали:

IT>Это всё элементы Entity Service (в частности это — Change Tracking), которых в BLT нет. Пока.
А может и не надо? Или только где-нибудь с боку, чтобы можно было выкинуть...

Здравствуйте, IB, Вы писали:

IT>>Это всё элементы Entity Service (в частности это — Change Tracking), которых в BLT нет. Пока.
IB>А может и не надо? Или только где-нибудь с боку, чтобы можно было выкинуть...

Ну не надо так не надо.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, IB, Вы писали:

IT>>>Это всё элементы Entity Service (в частности это — Change Tracking), которых в BLT нет. Пока.
IB>>А может и не надо? Или только где-нибудь с боку, чтобы можно было выкинуть...

IT>Ну не надо так не надо.

а хотелось бы, но именно так, чтобы оно работало ровно тогда, когда надо... в общем, привода бы иметь хотелось.

Здравствуйте, ili, Вы писали:

ili>а хотелось бы, но именно так, чтобы оно работало ровно тогда, когда надо... в общем, привода бы иметь хотелось.

DbManager всё равно придётся отстёгивать от linq-провайдера, а там уже дело техники/желания.

Здравствуйте, Игорь Ткачёв, Вы писали:

Поддержка наследования в BLToolkit выполнена по образу и подобию наследования в Linq To SQL.

Почему именно так? Ведь теперь базовый класс обязан "знать" обо всех своих наследниках. А это не дает разбить модель на независимые части.

Здравствуйте, Plotyan, Вы писали:

P>Почему именно так? Ведь теперь базовый класс обязан "знать" обо всех своих наследниках. А это не дает разбить модель на независимые части.

Варианты?

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Plotyan, Вы писали:

P>>Почему именно так? Ведь теперь базовый класс обязан "знать" обо всех своих наследниках. А это не дает разбить модель на независимые части.

AVK>Варианты?

Ну собственно знать о параметрах наследования (т.е. о типе и значении дискриминатора) нужно только при работе с наследником. Вот и указывать их в определении класса-наследника, т.е. только его и помечать атрибутом InheritanceMapping. Это, кстати, позволит для разных наследников использовать разные дискриминаторы.

Здравствуйте, Plotyan, Вы писали:

P>Ну собственно знать о параметрах наследования (т.е. о типе и значении дискриминатора) нужно только при работе с наследником. Вот и указывать их в определении класса-наследника, т.е. только его и помечать атрибутом InheritanceMapping. Это, кстати, позволит для разных наследников использовать разные дискриминаторы.

А как об этом наследнике узнает собственно меппер? Сканировать все сборки, или явно где то их сбоку регистрировать?

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Plotyan, Вы писали:

P>>Ну собственно знать о параметрах наследования (т.е. о типе и значении дискриминатора) нужно только при работе с наследником. Вот и указывать их в определении класса-наследника, т.е. только его и помечать атрибутом InheritanceMapping. Это, кстати, позволит для разных наследников использовать разные дискриминаторы.

AVK>А как об этом наследнике узнает собственно меппер? Сканировать все сборки, или явно где то их сбоку регистрировать?

По идее тем же способом, каким он узнает о сборке, в которой определен базовый класс.

Кстати, каким? Извиняюсь за незнание азов, но моё знакомство с BLToolkit измеряется в минутах, статья была прочитано только что.

Здравствуйте, Plotyan, Вы писали:

P>По идее тем же способом, каким он узнает о сборке, в которой определен базовый класс.

При чем тут сборка? Я спрашиваю про типы. Базовый тип указывается в запросе явно, как следствие мепперу сразу доступны все наследники. А вот если как ты предлагаешь — мепперу о наследниках узнать как?

P>Кстати, каким? Извиняюсь за незнание азов, но моё знакомство с BLToolkit измеряется в минутах, статья была прочитано только что.

Никаким. Базовый класс в запросе ты указываешь явно.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Plotyan, Вы писали:

P>>По идее тем же способом, каким он узнает о сборке, в которой определен базовый класс.

AVK>При чем тут сборка? Я спрашиваю про типы. Базовый тип указывается в запросе явно, как следствие мепперу сразу доступны все наследники. А вот если как ты предлагаешь — мепперу о наследниках узнать как?

Так же, как и о базовом типе.

P>>Кстати, каким? Извиняюсь за незнание азов, но моё знакомство с BLToolkit измеряется в минутах, статья была прочитано только что.

AVK>Никаким. Базовый класс в запросе ты указываешь явно.

Значит, явно указать в запросе наследника. Код из статьи:

from p in db.DiscontinuedProduct
select p;

или

from c in db.Product
where c is Northwind.DiscontinuedProduct
select c;

В первом случае тип наследника известен на момент создания "контекста" и маппер сможет разобраться с наследованием. Во втором это придется делать во время разбора выражения.

Здравствуйте, Plotyan, Вы писали:

Не получится. Вот такой запрос

from c in db.Product select c;

должен вернуть объекты не родительского типа, а наследников.

Здравствуйте, AndrewVK, Вы писали:

AVK>При чем тут сборка? Я спрашиваю про типы. Базовый тип указывается в запросе явно, как следствие мепперу сразу доступны все наследники. А вот если как ты предлагаешь — мепперу о наследниках узнать как?

аналогом IObjectFactory?

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Plotyan, Вы писали:

IT>Не получится. Вот такой запрос

IT>

IT>from c in db.Product select c;
IT>

IT>должен вернуть объекты не родительского типа, а наследников.

вот кстати, допустим у продукта есть такой наследник (наследование в одной таблице):

public class ProductEx : Product
{
    public int SomeValue { get; set; }
}

то с приведенного запроса он тоже выберется, его создание я могу разрулить IObjectFactory, но св-во SomeValue будет незаполненным?

Здравствуйте, IT, Вы писали:

IT>Не получится. Вот такой запрос

IT>

IT>from c in db.Product select c;
IT>

IT>должен вернуть объекты не родительского типа, а наследников.

Хм, тут не понял. Если Product — это базовый класс, то тут два варианта:
1. запрос возвращает все записи, включая всех наследников, в виде Product.
2. запрос возвращает только объекты класса Product, без наследников.

В первом случае все хорошо, а во втором да, нужно знать обо всех наследниках, чтобы их не выбрать. Но вроде первый вариант более логичен?

Здравствуйте, Plotyan, Вы писали:

P>Хм, тут не понял. Если Product — это базовый класс, то тут два варианта:
P> 1. запрос возвращает все записи, включая всех наследников, в виде Product.
P> 2. запрос возвращает только объекты класса Product, без наследников.

Если есть наследование, то должен быть полиморфизм, иначе все бессмысленно. А если есть полиморфизм, то когда я обращаюьс к абстрактному Product, реально должны создаваться экземпляры конкретных наследников.
P.S. Вообще, ИМХО, если уж заморачиваться наследованием, то нужно поддержать все три общеприменимых типа.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Plotyan, Вы писали:

P>>Хм, тут не понял. Если Product — это базовый класс, то тут два варианта:
P>> 1. запрос возвращает все записи, включая всех наследников, в виде Product.
P>> 2. запрос возвращает только объекты класса Product, без наследников.

AVK>Если есть наследование, то должен быть полиморфизм, иначе все бессмысленно. А если есть полиморфизм, то когда я обращаюьс к абстрактному Product, реально должны создаваться экземпляры конкретных наследников.

Таки да, торможу...

Здравствуйте, Игорь Ткачёв, Вы писали:

ИТ>...

Можно ли задать параметры ассоциаций и наследования через XML схему маппинга?