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

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

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

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

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

Если вы не сохраняете все объекты на одной диаграмме EF, как вы поддерживаете целостность данных, например "Заказы" не могут существовать без "Заказчика"? Является ли это единственным функция репозитория для загрузки данных просто для проверки целостности или мы пытаемся "поймать/поймать" на ошибках ссылочной целостности базы данных?
Разве вы не создали бы диаграмму EF для каждого объекта?. Например, я не ожидал бы изменений в клиенте и изменений в продукте, который будет написан вместе, поскольку у них ничего нет делать друг с другом (иметь их на одной диаграмме, чтобы они были записаны вместе). Или область EF-диаграммы охватывает все аналогичные объекты, хранящиеся на одном и том же носителе?

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

Ответ 1

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

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

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

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

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

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

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

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

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

Кроме того, для некоторых советов и трюков о том, как вы можете разделить одну крупную модель сущности на более мелкие при повторном использовании типов, взгляните на: Работа с большими моделями в инфраструктуре Entity - Part 2

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

Ответ 2

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

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

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

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

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, но тогда у вас есть другие "проблемы" при работе через реализацию, и большинство людей используют сопоставление по умолчанию, поэтому на таких форумах не будет много подходящих вопросов и ответов.

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

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