asp.net mvc модульное приложение howto / рекомендации

Question

Есть ли у кого-нибудь рекомендации по сборке ASP.Net MVC приложения модульным способом? Я имею в виду некоторые посты в блогах / учебные пособия и т. Д. Я только что прочитал пример поста MEF от Hammet и ASP.NET MVC , но я не нахожу MEF достаточно зрелым, чтобы использовать его в производстве. Я не смог отыскать другие релевантные сообщения на эту тему ...

Я знаю, что мог бы достичь модульности, реализуя собственный ControllerProvider и некоторый механизм проверки плагинов, но я хотел бы изучить еще несколько подходов / передовых методов, прежде чем я начну переопределять колесо:)

---

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

Я не хочу обсуждать здесь какую-либо подключаемую архитектуру модель + сервис - только часть ASP.Net M VC .

Answer 1

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

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

Answer 2

Я нашел статью, в которой рассматриваются некоторые фундаментальные требования, о которых вы говорите. К сожалению, статья была устаревшей на год с использованием ASP.NET MVC 3, поэтому я переписал ее и протестировал методологию, чтобы она работала с ASP.NET MVC 4. Вы можете прочитать ее здесь .

Answer 3

MVC Portable Areas может быть хорошим решением этой проблемы

Answer 4

В качестве отправной точки вы можете взять некоторые идеи из этой статьи:

Spark View Engine - Модульность

И пример кода:

spark / src / Образцы / Модули

Код находится в дереве Spark View Engine (это очень хороший и мощный проект), но не имеет к нему никакого отношения. Он использует Castle для создания зависимостей и тому подобного.

Между прочим, я возился с MEF, но на самом деле я не вижу преимуществ прямо сейчас, и то, что мне нужно было сделать, можно сделать с помощью Castle и некоторых инструментов (помощников для запроса сборок и тому подобного) .

Answer 5

Поддержка частичных запросов для рендеринга контроллеров третьей части полностью поддерживается в MVC, посмотрите на этот пост: http://blog.codeville.net/2008/10/14/partial-requests-in-aspnet-mvc/

Очевидно, что модуль в MVC будет содержать по крайней мере контроллер и одно или несколько представлений. Но, возможно, то, что вы хотели, это лишь немногие, и поэтому гораздо проще переписать контроллер, чем если бы это была традиционная архитектура WebForms.

Или, возможно, вы хотите заменить источник данных, просто переопределить методы в объекте Model, и все готово. Это основной принцип MVC: вы разделяете разные уровни логики и вынуждены это делать, в отличие от WebForms, которые все еще позволяют вам делать SQL прямо в вашем представлении, если вы ссылаетесь.

(MVC также поддерживает его не по замыслу, а по наследству.)

Answer 6

Я понимаю, что на этот вопрос уже дан ответ. Но я искал более актуальные ответы на эту тему. Я посмотрел на Области, как предполагает оригинальный ответ, но также натолкнулся на следующие ссылки ( Часть 1 и Часть 2 ) от Ливиу Игнат, который ответил на этот вопрос с помощью подключаемого модуля перспектива модуля.

Answer 7

Основные аргументы в пользу модульности всегда одинаковы ...

• Тестируемость
• ремонтопригодность
• Простота развертывания