EntityFramework: нарезать или не нарезать?

Question

Так что я только начинаю с Entity Framework. Я работаю с очень большой, существующей базой данных. Я хочу использовать EF для создания моделей, которые являются «кусочками» всей базы данных. Эти кусочки соответствуют 1 аспекту заявки. Это правильный взгляд на это, или я должен попытаться смоделировать всю базу данных в 1 EDMX?

Позвольте привести вам вымышленный пример:

Предположим, что одной из многих вещей, которые содержит эта база данных, является информация о счетах клиентов. Я чувствую, что хочу создать модель EF, которая просто фокусируется на таблицах, с которыми должен взаимодействовать модуль Customer Billing. (тогда эта модель НЕ будет использоваться для других модулей в приложении, скорее, те же самые таблицы могут появиться в других небольших EF-моделях). Это позволило бы мне использовать возможности концептуальной модели EF (наследование и т. Д.), Чтобы создать представление, правильное для выставления счетов клиентам, не беспокоясь о влиянии этой модели, скажем, в службу поддержки (даже если два модуля совместно используют некоторые таблицы)

Это звучит правильно?

Answer 1

Звучит правильно для меня.В конце концов, сущность модели сущностей заключается в предоставлении набора бизнес-объектов с поддержкой постоянства на уровне , который соответствует требуемой бизнес-логике.

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

Answer 2

Я бы предпочел использовать подход срезов, основанный на следующих причинах:

• Если у вас огромная база данных с множеством таблиц, тогда будет сложно управлять массивной моделью сущностей.
• Проще поддерживать специфичные для приложения / домена сущности, так как структура сущностей не является таблицей для сопоставления сущностей, вы можете создавать собственные сущности, а также комбинировать и разбивать таблицы по сущностям.