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

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

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

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

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

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

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

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

Итак

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

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

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