Entity Framework 4, наследование или расширение?

Я пробовал нечто подобное, как вы описываете, и основная проблема, которую я вижу, заключается в том, что вы не можете создать ObjectSet<T> для производного типа. Так что у вас не будет ObjectSet<Person> репозитория. Если вы получите все свои сущности, например, из сущности BusinessObject, вы сможете работать только с ObjectSet<BusinessObject>. Если вы хотите запросить только репозиторий Person, вы можете написать запрос типа Context.BusinessObjectSet.OfType<Person>().ToList(), но я думаю, что он не будет генерировать правильный SQL под капотом и сначала получит полные строки BusinessObject, а затем отфильтрует объекты Person в памяти. Так что я думаю, что это будет иметь огромное влияние на производительность.

Я немного опоздал на вечеринку, но у меня были те же вопросы, что и у вас, относительно наследования в EF, и я нашел для вас довольно хорошее резюме. Это отрывок из книги Джули Лерман Programming Entity Framework.

После прочтения вот мои выводы по теме:

1) В целом, каковы плюсы и минусы наследования по сравнению с расширением. Плюсы действительно зависят от выбранной вами стратегии за столом. См. Как выберите стратегию наследования — блог MSDN. Однако они только «за» при условии, что вы уже решили вообще использовать наследование. И это не решение принимать легкомысленно.

Минусов много, но самым большим является невозможность добавить существующий объект в базу данных в качестве производного объекта. Например: у меня есть Student, который наследуется от Person. Существует запись человека для Джона Смита. Через некоторое время мне нужно, чтобы Джон Смит стал студентом. Ну очень плохо. Это невозможно. (По крайней мере, без обхода EF с помощью хранимой процедуры).

2) В моем конкретном примере выше, что было бы более подходящим? - В вашем примере вы должны просто добавить эти столбцы (entityId, datecreated, datemodified) в таблицы, которые в них нуждаются. Вы можете использовать сложный тип для datecreated и datemodified, но в этом нет необходимости, если вы не очень строгий парень DRY. Даже тогда это может быть излишним. Причина в том, что если у вас есть сущность, вы никогда не сможете добавить эту сущность в другую производную таблицу. Человек (который является BaseEntity) не может быть добавлен в качестве Студента позже. Кроме того, написание запросов LINQ было бы намного сложнее, чем необходимо. Алекс это уже показал.

3) Если мой пример плохой для одного или обоих, какой хороший пример для использования наследования и использования расширения? - Как правило, если вы можете сделать свой базовый тип абстрактным, наследование может работать на вас. Но вы все равно должны сначала рассмотреть другие варианты. Если ваш базовый тип будет где-то напрямую создан, просто используйте композицию. Наследование становится очень проблематичным, когда дело доходит до фактического запроса и вставки записей.

Таким образом, то, что вы можете выполнять наследование в EF, не означает, что вы должны это делать. Если вам может сойти с рук дизайн без наследования, то сделайте это во что бы то ни стало.

Одним из недостатков использования наследования в вашей модели является то, что вы не сможете отображать свою модель через службы данных WCF (OData), поскольку в настоящее время она не поддерживает производные объекты.