Рекомендации по составлению веб-приложений ASP.NET MVC (MEF, Районы, DI)

В настоящее время я выясняю, как реструктурировать архитектуру существующего не очень модульного приложения ASP.NET MVC 3.0. У меня есть плагиновая структура, чтобы сделать существующий проект расширяемым.

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

  • Области MVC в отдельных проектах

Для каждого плагина я хочу создать отдельный проект ASP.NET MVC, содержащий контроллеры, представления и модели просмотра для плагина. Модуль "Сотрудник" будет содержать область для отображения, создания, обновления и удаления сотрудников. Однако это звучит хорошо, AreaRegistration требуется разместить все области в каталоге "bin". Я нашел способ разместить проекты Area непосредственно в папке Areas и разрешить сборки Area из папки "/Areas/[AreaName]/bin":

BuildManager.AddReferencedAssembly.Add(Assembly.LoadFrom(…));
AppDomain.CurrentDomain.AssemblyResolve += ResolveAssemblies;

Это работает достаточно хорошо и позволяет мне развернуть плагины в папке Areas основного проекта. Мне нравится, что я использую функцию Areas, которая предоставляется из коробки ASP.NET MVC.

  • Переносимые области MVC (MVCContrib)

http://elegantcode.com/2012/04/06/mvc-portable-areas/

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

  • Модули на основе MVC с использованием MEF

http://www.fidelitydesign.net/?p=104

Чтобы создать слабосвязанные службы в других проектах, я в большой степени полагаюсь на MEF. Таким образом, я подумал, что было бы неплохо использовать его для открытия ASP.NET MVC Modules/Plugins. Я бы в конечном итоге использовал ControllerFactory, который будет создавать экземпляры Controllers, экспортированные с помощью атрибута Export. Таким образом, я бы полностью контролировал создание экземпляра плагина и мог использовать MEF для получения сервисов. Однако использование MEF действительно требует гораздо большей работы, чем использование областей MVC, которые разрешают контроллеры из коробки.

  • Entity Framework для проектов плагинов

Одна из проблем, с которыми я не смог решить до сих пор, заключается в том, как распределять сущности по отдельным проектам плагинов. В настоящее время мы используем подход Database First, который состоит из одного файла модели .edmx, который содержит все сущности. Даже с DbContext или Code First невозможно использовать несколько классов DbContext для одной базы данных. Одной из идей было бы использовать MEF для загрузки объектов из разных плагинов в центральный класс DbContext. Однако я не знаю, поддерживается ли это и/или рекомендуемая настройка.

Ответ 1

Другой вариант - использовать мой Griffin.MvcContrib. Он заботится обо всех сантехниках для вас и позволяет писать виды и использовать области с небольшими изменениями кода.

Используйте его вместе с контейнером IoC, чтобы получить мощную систему плагинов.

Вот статья, демонстрирующая, как: http://www.codeproject.com/Articles/386674/ASP-NET-MVC-3-plug-in-architecture-using-Griffin-M