Работа с EntityFramework в нескольких проектах

Question

Я борюсь с тем, как лучше разбить модель домена на несколько проектов Visual Studio. Я работаю с шаблонами EntityFramework 4 и Enterprise-type, чтобы рационализировать систему, которую можно повторно использовать для различных приложений. В конце концов я хочу получить набор библиотек классов DLL, которые можно использовать в разных веб-приложениях.

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

CRM / пользовательские таблицы являются ядром системы. Платформы CMS и электронной коммерции используют пользовательские таблицы CRM. Я хочу определить базовую модель домена, с которой связываются / наследуются модели доменов CMS и eCommerce.

Пока у меня есть три визуальных студийных проекта:

• MyNamespace.Model.Core
• MyNamespace.Model.CMS
• MyNamespace.Model.Commerce

В каждой из этих моделей есть файл EDMX модели предметной области Entity Framework. EDMX содержит все соответствующие таблицы для каждой. Это означает, что файл EDMX для проектов CMS и Commerce содержит некоторые пользовательские таблицы. Я теоретически мог бы иметь одну большую модель EF и поместить все POCO в один класс, но это не очень расширяемо.

Проекты также содержат POCO для каждой из таблиц (они, вероятно, должны быть в отдельном проекте, но пока вещи не отсортированы, они могут оставаться на своих местах!).

Когда я использую модель предметной области в слое обслуживания с Единицей Работы, я хочу использовать только один ObjectContext (это фактически оболочка IObjectContext, которая нацелена на EF ObjectContext). По этой причине я дал каждому из файлов EDMX одно и то же имя контейнера сущностей и пространство имен.

Вопросы:

1. Это правильная вещь?
2. Если в одном и том же пространстве имен есть модели EF с одним и тем же именем контейнера (хотя и в разных проектах), это вызовет проблемы, если таблица / объект повторяется (например, клиенты) в этих разных моделях?

Answer 1

Справедливые очки, некоторые комментарии:

1. Это самая большая проблема, насколько я могу видеть.Я думаю, что это можно обойти, используя (например) CRM.Person, где это уместно, и Commerce.Person, где это уместно.Я думаю, что я пытаюсь найти общую модель POCO с моделью (ами) предметной области EF, расположенной ниже.Меня не очень волнует, как строится модель (и) EF иначе, чем она должна быть разумно структурирована.

2. Опять же, следующая самая большая проблема.Решено до некоторой степени с помощью дублированных сущностей в разных контекстах, но тогда это будет означать, что некоторые свойства навигации будут недоступны.Например, CRM.Person не будет иметь свойства заказов, доставки и т. Д., Которые есть у Commerce.Person, даже если они являются «одним и тем же» человеком в БД.

3. на основе отраженийлогика (на данный момент) для меня не важна.

4. Согласовано.Следовательно, почему я хочу как-то перейти к одному контексту

5. Единица работы на самом деле является IUnitOfWork и DI-ed в репозитории и должна быть независимой от EF.

6. Не согласен.Идея состоит в том, чтобы перейти к основному приложению, которое может быть расширено при необходимости.Например, будущий проект может включать в себя театральные заказы.Это будет связано с ядром Commerce, но я бы не хотел перепрограммировать приложение Commerce для его учета.Насколько мне известно, перестройка моделей EDMX не идеальна.Может быть, единственный путь.

   1. Я вижу, как это могло произойти!

На первый взгляд кажется, что это недостатокEF, хотя может быть очень веская причина не делать то, что я хочу делать.Возможно, Microsoft должна включить какой-то метод, при котором две модели домена EDMX с одинаковым именем контейнера объединяются во время выполнения.Фактически (и, если не сказать лучшего слова), модели EDMX станут «частичными», и до тех пор, пока не будет никаких столкновений, я не вижу в этом слишком много неправильных?

Answer 2

Ну, EF очень новый, и все же почти все, как вы, экспериментируют и находят новые способы создания лучших систем.Так что прямого ответа не будет, но я могу изложить свои мысли и проблемы, с которыми я уже столкнулся.

Проблемы с несколькими EDMX

1. Совместное использование сущностей для построения более общей логики будет затруднено, так как в конечном итоге у вас будут одинаковые именованные сущности в нескольких контекстах.
2. Если они будут храниться в одной базе данных, в будущем вам могут понадобиться объединения и отношения между двумя объектами, которые находятся в другом контексте.
3. Написание логики на основе отражений будет невозможно.
4. Работа в разных контекстах будет сложной.
5. EF уже реализует единицу работы, и RIA Services поверх нее будет хорошим кандидатом, вместо того, чтобы полностью реализовывать ее.
6. Хранение всего в одном контексте позволит вам создать расширяемое приложение.И в основном весь код будет сгенерирован автоматически, поэтому он не будет иметь большого значения.
7. Мы попробовали это, и мы поняли, что позже ему понадобится много склеивающего кода, и все станет грязным, поскольку повторение кода и отчетов стало большой проблемой, и мы наконец переместили все в один контекст.

Если я собираюсь хранить все в одной базе данных, я вижу это как один репозиторий.