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

Question

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

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

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

Если предположить, что это правильно, вот мои вопросы:

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

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

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

Answer 1

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

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

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

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

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

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

Для более детального обсуждения, взгляните на Working With Large Models In Entity Framework – Part 1

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

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

Кроме того, некоторые советы и приемы, о том, как вы можете разделить одну большую модель лица на более мелкие, в то время как повторное использование типов, обратите внимание на: Working With Large Models In Entity Framework – Part 2

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

Answer 2

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

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

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

«Но нормализация хорошая вещь, правильно?» Хорошо, если вы используете реляционную базу данных да. «Но почему это имеет значение, если я использую EF?» Обычной «нормализованной» таблицей является Адрес. Возможный сценарий: Компания (местоположение бизнеса/офиса) и Контакт (может быть «удаленным» работником, чтобы они не находились в бизнес-месте), и оба они имеют 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, но тогда у вас есть другие «проблемы» при работе через реализацию, и большинство людей используют картографирование по умолчанию, поэтому на таких форумах не будет много подходящих вопросов и ответов.

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

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