Entity Framework 4, наследующий и расширяющий?

Question

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

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

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

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

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

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

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

Так

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

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

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

Answer 1

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

Answer 2

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

Answer 3

Я немного опаздываю на вечеринку, но у меня были те же вопросы, что и вы относительно наследования в EF, и нашли довольно хорошее резюме для вас, чтобы читать. Это excerpt from Julie Lerman's book Programming Entity Framework.

Прочитав ее, вот мои выводы по теме:

1) В общем, какие плюсы/минусы наследования против расширения - Доводы действительно зависит от стратегии таблицы вы выбираете. См. How to choose an Inheritance Strategy - MSDN Blog. Однако они являются только «профессионалами», исходя из предположения, что вы уже решили использовать наследование вообще. И это не решение принять легкомысленно.

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

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

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

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