Entity Framework 4: имеет ли смысл создавать единую диаграмму для всех объектов?

Question

Я написал несколько предположений относительно Entity Framework, а затем несколько вопросов (поэтому, пожалуйста, исправьте, где я ошибаюсь).Я пытаюсь использовать POCO с EF 4.

Мои предположения:

• Для диаграммы EF может существовать только один контекст данных.
• Контексты данных могут ссылаться наболее чем одна сущность.
• Если у вас есть два источника данных, например, сервер MS SQL и Oracle, для доступа к данным EF требуются две разные диаграммы.
• Контекст данных диаграммы EF - это «Единица измерения».работы », имея единый Save () для чего-либо на диаграмме.(Конечно, вы могли бы обернуть его в класс UnitOfWork, но он по сути выполняет те же обязанности).

Предполагая, что это правильно, вот мои вопросы:

• Если вы не держите все сущности на одной диаграмме EF, как вы сохраняете целостность данных, например, «Заказы» не могут существовать без «Заказчика»? Является ли это исключительно функцией хранилища для загрузки данныхпросто для проверки целостности, или мы «пытаемся / ловим» ошибки базисной целостности базы данных?

• Не хотите ли вы создать диаграмму EF для каждого объекта? ДляНапример, я не ожидал бы, что изменения для клиента и изменения в продукте будут написаны вместе, поскольку они не имеют никакого отношения друг к другу (наличие их на одной диаграмме приведет к тому, что они будут написаны вместе).Или же сфера действия диаграммы EF охватывает все похожие объекты, хранящиеся на одном носителе?

Является ли нормой разделение таких объектов или просто одна диаграммадержа все сущности?Я бы подумал о последнем, но мышление одолевает меня.

Answer 1

Наличие одного большого EDM, содержащего все сущности, обычно НЕ является хорошей практикой и не рекомендуется.
Использование одного большого EDM вызовет несколько проблем, таких как:

Проблема производительности во время загрузки метаданных:
По мере увеличения размера файлов схемы время, необходимое для анализа и создания модели в памяти для этих метаданных, также будет увеличиваться.

Ошибка производительности при создании представления:
Генерация представлений - это процесс, который компилирует декларативное сопоставление, предоставляемое пользователем, в представлениях Entity Sql на стороне клиента, которые будут использоваться для запроса и сохранения сущностей в базе данных. Процесс запускается в первый раз, когда происходит запрос или SaveChanges. Производительность шага генерации представления зависит не только от размера вашей модели, но и от того, насколько взаимосвязана модель. Если два объекта связаны через цепочку наследования или ассоциацию, считается, что они связаны. Аналогично, если две таблицы связаны через внешний ключ, они связаны. По мере увеличения числа связанных сущностей и таблиц в ваших схемах увеличивается стоимость создания представлений.

Загроможденная дизайнерская поверхность:
Когда вы генерируете модель Edm из большой схемы базы данных, поверхность конструктора загромождена множеством сущностей, и было бы трудно понять, как выглядит ваша модель сущности в целом. Если у вас нет хорошего обзора модели сущностей, как вы собираетесь ее настраивать?

Опыт работы с Intellisense невелик:
Когда вы генерируете модель Edm из базы данных, скажем, с 1000 таблицами, вы получите 1000 различных наборов сущностей. Представьте себе, как будет работать ваш intellisense при вводе «context» в окне кода VS.

Загроможденные пространства имен CLR:
Поскольку схема модели будет иметь одно пространство имен EDM, сгенерированный код поместит классы в одно пространство имен.

Для более подробного обсуждения смотрите Работа с большими моделями в Entity Framework - Часть 1

Решение:
Хотя для этого нет готового решения, но оно предлагает вместо этого Естественно отключенные подмножества в вашей модели , что означает, что в зависимости от вашей доменной модели вы должны придумать различные наборы моделей предметной области, каждая из которых содержит связанные объекты, в то время как каждый набор не связан и не связан с другим. Никакие иностранные ключи между ними не могут быть хорошим знаком для разделения. И это имеет смысл, потому что в большой модели, как правило, вашему приложению не требуется, чтобы все таблицы в базе данных были сопоставлены с одной Entity Model для работы.

Даже если такое разделение невозможно на 100% - это означает, что существуют подмножества таблиц, в которых есть внешние ключи для других таблиц в базе данных - все равно рекомендуется разделять их. Когда вы это сделаете, вам придется взять на себя ответственность за правильную настройку внешнего ключа. Не было бы свойства навигации, которое позволило бы вам получить сущность, представляющую этот внешний ключ. Конечно, вы можете вручную запросить эту сущность в другом контейнере, если это необходимо.

Кроме того, для получения некоторых советов и рекомендаций о том, как разделить одну модель больших объектов на более мелкие при повторном использовании типов, ознакомьтесь с: Работа с большими моделями в Entity Framework - часть 2

О тебевопрос: Заказ и Заказчик принадлежат к одному и тому же естественному домену и должны храниться в одном EDM. Как я уже сказал, вы можете разбросать их по 2 различным моделям данных сущностей, но тогда вам придется взять на себя ответственность за установку соответствующих внешних ключей, или вы получите исключения времени выполнения, с одинаковым токеном, Customer и Продукт должен храниться в отдельных моделях данных объекта. Следуя этим правилам, вы можете создать четко определенный дизайн набора доменов на уровне доступа к данным.

Answer 2

Я понимаю, что этот вопрос был о EF4 , но я уверен, что многие люди, которые только сейчас "делают переход", окажутся здесь через Google и прочтут этот и утвержденный ответ и примут решенияна основе этого, даже если они используют EF5 (или EF4.4, если вы застряли на .Net 4.0)

EF5 позволяет несколько диаграмм на edmx.Это большое дело, по крайней мере для моей команды, потому что оно позволяет нам визуально разделять сущности, не требуя отдельных файлов EDMX.Точки доктора Зима все еще действительны, за исключением (очевидно) «загроможденной дизайнерской поверхности».

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

"Но нормализация - это хорошо , верно?"Хорошо, если вы используете реляционную базу данных, да.«Но почему это важно, если я использую EF?»Распространенной «нормализованной» таблицей является Address.Возможный сценарий: компания (место нахождения офиса / офиса) и контакт (может быть «удаленным» работником, поэтому они не находятся в месте нахождения предприятия), и у них обоих есть FK, указывающий на адрес.Используя один файл edmx для компании и один для контакта (даже с разными пространствами имен), которые оба содержат таблицу адресов, код скомпилируется, но во время выполнения вы получите такую ​​красоту:

Multiple types with the name 'Address' exist in the EdmItemCollection
in different namespaces. Convention based mapping requires unique names
without regard to namespace in the EdmItemCollection

Вы можете изменитьотображение, которое используется в EF, но при работе с реализацией возникают другие «проблемы», и большинство людей используют отображение по умолчанию, поэтому на форумах, подобных этому, не будет много соответствующих вопросов и ответов.

Вы также можете переименоватьНазвание модели для таблицы адресов - «ContactAddress» и «CompanyAddress» соответственно, но это создает иллюзию того, что это разные типы, когда на самом деле это не так.Итак, они являются различными типами в EF, но не в базе данных, и, как я сказал, большинство из нас "живут" в мире привязки к EF к существующей системе с существующим хранилищем данных, котороереляционная база данных.

Это уже многословный «ответ», поэтому я на этом остановлюсь.Я просто хотел убедиться, что люди, которые приземлились здесь, потому что искали «множественный edmx» и не осознавали, что между EF4 и EF5 есть существенная разница, были осведомлены и поняли, что им, возможно, потребуется провести еще какое-то расследование.