В БД есть сущность каталог. В зависимости от значения ParentId каталог может быть корневым или дочерним (если ParentId is null — корневой, иначе — дочерний). Для добавления каталогов в СУБД написано 2 хранимые процедуры: одна для корневых каталогов, другая для дочерних. Конечно, можно было написать логику добавления общую и для корневых, и для дочерних каталогов... но так действительно проще: система такова, что при создании корневых каталогов некоторые параметры не нужны.
Я вот думаю, как бы красиво замапить эти хранимки в Entity Framework: сущность-то одна, а хранимки две. Есть идея заюзать наследование: от абстрактной сущности BaseCatalog (хранящей все атрибуты) наследовать RootCatalog и Catalog (и каждой из этих сущностей назначить соответствующую хранимую процедуру на вставку). А затем в DAL'е сделать функцию AddCatalog, которая в зависимости от значения ParentId будет создавать либо RootCatalog, либо Catalog.
Меня смущеает то, что сущности RootCatalog и Catalog будут пустыми... и какое же это тогда наследование?!
Подскажите, может, есть более красивые решения.
Здравствуйте, Idsa, Вы писали:
I>В БД есть сущность каталог. В зависимости от значения ParentId каталог может быть корневым или дочерним (если ParentId is null — корневой, иначе — дочерний). Для добавления каталогов в СУБД написано 2 хранимые процедуры: одна для корневых каталогов, другая для дочерних. Конечно, можно было написать логику добавления общую и для корневых, и для дочерних каталогов... но так действительно проще: система такова, что при создании корневых каталогов некоторые параметры не нужны. I>Я вот думаю, как бы красиво замапить эти хранимки в Entity Framework: сущность-то одна, а хранимки две. Есть идея заюзать наследование: от абстрактной сущности BaseCatalog (хранящей все атрибуты) наследовать RootCatalog и Catalog (и каждой из этих сущностей назначить соответствующую хранимую процедуру на вставку). А затем в DAL'е сделать функцию AddCatalog, которая в зависимости от значения ParentId будет создавать либо RootCatalog, либо Catalog. I>Меня смущеает то, что сущности RootCatalog и Catalog будут пустыми... и какое же это тогда наследование?! I>Подскажите, может, есть более красивые решения.
Действительно, не красиво и не оправдано (изврат, иными словами).
Да к тому же, у тебя ничего не получится. Чтобы замапить иерархию наследников на одну таблицу, нужно иметь в таблице поле дескриминатор, по которому EF будет определять к какому типу относится конкретная сущность. ParentId дескриминатором быть не может.
Лучше поправь свои хранимки, это дешево и эффективно.
Здравствуйте, stump, Вы писали:
S>Да к тому же, у тебя ничего не получится. Чтобы замапить иерархию наследников на одну таблицу, нужно иметь в таблице поле дескриминатор, по которому EF будет определять к какому типу относится конкретная сущность. ParentId дескриминатором быть не может.
Хм... А почему это поле ParentId не может быть дескриминатором? Я планировал задать в RootCatalog условие ParentId is null, а в каталог — ParentId is not null. Разве не сработает?
Здравствуйте, Idsa, Вы писали:
I>Здравствуйте, stump, Вы писали:
S>>Да к тому же, у тебя ничего не получится. Чтобы замапить иерархию наследников на одну таблицу, нужно иметь в таблице поле дескриминатор, по которому EF будет определять к какому типу относится конкретная сущность. ParentId дескриминатором быть не может. I>Хм... А почему это поле ParentId не может быть дескриминатором? Я планировал задать в RootCatalog условие ParentId is null, а в каталог — ParentId is not null. Разве не сработает?
Попробуй, чего гадаешь. ParentId тебе придется использовать в navigation properties. Будет конфликт и прикомпиляции схемы EF будет ругаться (в beta 3, во всяком случае, так было).
Здравствуйте, stump, Вы писали:
S>Попробуй, чего гадаешь. ParentId тебе придется использовать в navigation properties. Будет конфликт и прикомпиляции схемы EF будет ругаться (в beta 3, во всяком случае, так было).
Честно говоря, я не понял, зачем "ParentId использовать в navigation properties.
Я удалил из BaseCatalog атрибут ParentId, добавил 2 сущности (RootCatalog и Catalog), соединив каждую из них связью наследования с BaseCatalog:
После этого появилась ошибка "Entity types RootCatalog, Catalog are mapped to table LibraryCatalogs without discriminating conditions on all mappings to the table. Оказывается, это баг дизайнера: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3324129&SiteID=1, и эту ошибку можно проигнорировать.
Таким образом, у меня получилось реализоваь задуманное... правда, пожалуй, использовать на практике я этого не буду
Здравствуйте, Idsa, Вы писали:
I>Здравствуйте, stump, Вы писали:
S>>Попробуй, чего гадаешь. ParentId тебе придется использовать в navigation properties. Будет конфликт и прикомпиляции схемы EF будет ругаться (в beta 3, во всяком случае, так было). I>Честно говоря, я не понял, зачем "ParentId использовать в navigation properties.
У тебя же дерево.
Здравствуйте, stump, Вы писали:
I>>Честно говоря, я не понял, зачем "ParentId использовать в navigation properties. S>У тебя же дерево.
Вы имеете в виду то, что в ParentId должен быть foreign key на Id?
Здравствуйте, Idsa, Вы писали:
I>Здравствуйте, stump, Вы писали:
I>>>Честно говоря, я не понял, зачем "ParentId использовать в navigation properties. S>>У тебя же дерево. I>Вы имеете в виду то, что в ParentId должен быть foreign key на Id?
Да, что-то типа того.
