Модульные приложения только с кодом Entity Framework и ASP.NET MVC

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

Это популярный подход, например. CRM с открытым исходным кодом, такие как SugarCRM или VTiger.

Этому подходу можно следовать в приложении asp.net mvc с использованием областей или (переносимых областей из вклада MVC), которые позволяют добавлять новые контроллеры и представления в отдельные сборки, не затрагивая основные библиотеки DLL.

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

Я заметил, что Orchard CMS достигает полной модульности за счет использования nHibernate (что показательно, учитывая, что у них есть поддержка Microsoft, а проект задумывался как демонстрация технологий). Nhibernate допускает такую ​​модульность благодаря подходу POCO. Каждая сущность/таблица определяется в отдельном файле, что, очевидно, подходит для модульных приложений.

Однако есть надежда на подход Entity Framework Code Only, который генерирует модель Edmx во время выполнения с использованием определений POCO. Кто-нибудь пробовал этот подход для распространения определений модели данных в отдельных подключаемых проектах?


person aaimnr    schedule 28.02.2011    source источник
comment
На данный момент кажется слишком ограниченным, но возможность такой расширяемости выглядит как веская причина для перехода.   -  person aaimnr    schedule 01.03.2011
comment
Это было задано давно, однако я хотел бы знать, что вы сделали @deadbeef. Я сталкиваюсь с аналогичной концептуальной проблемой   -  person MrJD    schedule 27.09.2012
comment
Я не добился такой модульности, придерживаясь центрального EDMX (тем не менее, это ужасное решение).   -  person aaimnr    schedule 12.10.2012


Ответы (1)


Я добился этого, используя EF Code First и комбинацию точек расширения графического интерфейса в основном модуле. Это привело к:

  • Каждый модуль обрабатывается как отдельное приложение (кроме графического интерфейса).
  • Каждый модуль имеет свою собственную базу данных (так как код сначала удаляет и воссоздает базу данных)
  • Каждый модуль может дублировать необходимые данные в другом модуле.
  • Каждый модуль представляет собой сервис.
  • Каждый модуль может расширять графический интерфейс через основные точки расширения через контейнер IoC.
  • Модули могут взаимодействовать с каждым через асинхронный обмен сообщениями (nServiceBus) и синхронный RPC (WCF).

Обратите внимание, что это корпоративное приложение, которое мы разработали для SOA.

С EF Code First, если вы управляете своей базой данных вручную (т. е. не удаляете и не создаете заново), вы можете использовать некоторые приведенные выше концепции и упростить ее. Вам может понадобиться собственный IDatabaseInitializer для его поддержки, но это должно быть возможно.

person JarrettV    schedule 28.02.2011
comment
Разве спрашивающий не просит одинаковые решения БД? - person John Farrell; 28.02.2011
comment
Правда, я ищу более простое решение. Тем не менее, этот подход весьма интересен (несмотря на то, что в большинстве ситуаций он излишен). - person aaimnr; 01.03.2011