Entity Framework 4, наследуя от расширения?

Question

Каковы преимущества / недостатки каждого метода?

Я знаю, что читал где-нибудь в книге или на этом сайте, почему использование наследования таблиц является дрянным для Entity Framework 4.

Например, почему бы не создать одну таблицу, у которой есть entityId, datecreated, datemodified, а затем все другие классы наследуют это в рамках Entity Framework?Тогда мои таблицы для всех других объектов не должны иметь эти столбцы.Тогда я могу сделать так, чтобы класс person унаследовал этот базовый класс, а затем конкретный человек унаследовал person.

Я не уверен в преимуществах этого, за исключением написания меньшего сценария SQL для создания базы данных ...

Недостатки, которые я вижу, заключаются в том, что это делает запрос / просмотр данных непосредственно в SQL большой болью в заднице (вся соответствующая информация разбита на множество таблиц), и я также спросил моего друга, который сказал:

"Самым большим преимуществом для меня является тот факт, что я не хочу, чтобы моя база данных полагалась на текущую структуру наследования моего приложения. Если по какой-либо причине я хотел изменить дизайнмоего приложения с точки зрения наследования, это не будет иметь значения, потому что мои данные не будут зависеть от моей текущей конструкции системы. Я думаю, что хранение данных - это просто хранение. База данных нормализована в соответствии с правильным дизайном базы данных, нонаследование - это программный выбор разработки приложений, а не хранения данных.помешает мне использовать его.Наследование - это очень сложная вещь для правильной разработки приложения.гораздо проще изменить код приложения, чем изменить и перенести данные базы данных, когда большинство менее опытных разработчиков подходят к проблеме, к которой они обращаются с наследованием.Я тоже, когда я только начал развиваться.это логично, имеет смысл.однако после долгого развития вы узнаете, что делегирование - действительно лучший способ (сервисы, вызывающие сервисы в случае soa), и что специализированные сервисы обеспечивают намного большее повторное использование, чем наследование. "

Что также имеет смысл для меня.

Итак

1) В общем, каковы плюсы / минусы наследования против расширения
2) В моем конкретном примере выше, что быбыть более подходящим?
3) Если мой пример дрянной для одного или обоих, каков хороший пример использования наследования и расширения?

Я использовал оба раньше, но я далек отопытный, я до сих пор не уверен, как справиться со всеми ситуациями.

10 Голосов: 8, более 100 просмотров, и никто не может расширяться? = (.

Answer 1

Я немного опоздал на вечеринку, но у меня были те же вопросы, что и у вас относительно наследования в EF, и я нашел довольно хорошее резюме для вас, чтобы прочитать.* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * [* [1). * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *} * * * * * * * * * * * * * * * * * * * * * * * * * * * * *.плюсы / минусы наследования против расширения - Плюсы действительно зависят от выбранной вами стратегии стола.См. Как выбрать стратегию наследования - MSDN Blog .Тем не менее, они всего лишь «плюсы», если предположить, что вы уже решили использовать наследование вообще.И это не решение, которое нужно принимать всерьез.

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

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

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

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

Answer 2

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

Answer 3

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