ASP.NET MVC - разделение большого приложения
Я был озадачен тем, что считаю противоречием в терминах: ASP.NET MVC утверждает, что он продвигает и поддерживает девиз "разделения интересов", что я считаю отличной идеей.
Тем не менее, кажется, что нет способа разделить контроллеры, модели или представления на их собственные сборки или разделить области на сборки.
С фиксированным Controller, Model а также View папки в вашем ASP.NET MVC, вы на самом деле создаете огромную кучу вещей. Это разделение интересов, правда? Похоже, совсем наоборот.
Так что мне интересно
Как создать решение ASP.NET MVC, которое будет разделять контроллеры, модель и папки с полными представлениями на отдельные сборки?
Как я могу поместить области ASP.NET MVC 2 в отдельные сборки?
или как еще вы управляете большим приложением ASP.NET MVC, которое имеет несколько десятков или даже более ста контроллеров, множество классов моделей и моделей представления и несколько сотен представлений?
5 ответов
Я думаю, что вы ищете области в ASP.Net MVC 2. Есть некоторые вещи, которые нужно раскомментировать в файлах CSProj, но после этого он скопирует представления при сборке. Я не думаю, что есть какое-то требование, чтобы Controller или же Model классы должны быть в той же сборке, что и представления.
Пошаговое руководство. Создание приложения ASP.NET MVC Areas с использованием нескольких проектов
Контроллеры: AFAIK, вам не нужно делать ничего особенного, чтобы бросать контроллеры в их собственную сборку. Самое большее, что вам нужно сделать, это переопределить метод GetControllerType вашего ControllerFactory.
Модели: нулевые ограничения на то, где вы размещаете свои модели. Хотя это неодобрительно, я регулярно использую постоянные объекты из DTO уровня Nhibernate/ ORM или DTO уровня WCF/ сервиса, которые расположены в отдельной сборке в качестве моих представлений. Это работает так же, используя WebForms.
Представления. Представления в отдельной сборке должны быть помечены как встроенный ресурс, и затем вы должны использовать пользовательский VirtualPathProvider, который знает, как получить представления из ресурса вместо файловой системы. представления из ресурса вместо файловой системы. Опять же, это тот же метод, который вы использовали бы для разработки WebForm.
Относительно mcintyre321 и его ответа "Переносимые области": связанный проект делает только что-то нестандартное и просто превращает существующие точки расширения MVC 2 в более простую в использовании абстракцию. Это едва ли "обычай" и более синтаксический сахар.
Вы управляете большим приложением MVC так же, как и любым другим крупным приложением. Я боюсь открывать 500-страничный проект WebForms, потому что вы никогда не знаете, что в каждом из этих кодов позади. С MVC отличная функциональность в основном на своем месте. Это совсем не наоборот.
Разделение кода на отдельные сборки ортогонально разделению задач. Где живет код, не является "проблемой". Разделение проблем связано с обязанностями и направлением зависимостей различных компонентов. Например, Views отвечают за рендеринг вывода, и контроллер знает о представлениях, но представления на самом деле не имеют глубоких знаний о контроллере.
Аналогичным образом, модели ничего не знают ни о представлениях, ни о контроллерах, но и представления, и контроллеры будут знать о модели.
Однако вернемся к вашему вопросу. Как указывает jfar, перемещение контроллеров и моделей в другую сборку тривиально легко и будет работать. Переместить представления в другую сборку сложнее. Встроенные ресурсы с настраиваемым поставщиком виртуальных путей - это один из способов, но не тот, который мы обычно рекомендуем для высокопроизводительного сайта. Но если это соответствует вашим потребностям, пойти на это.
MVC очень расширяемый и не требует соблюдения структуры папок Controller, View и Model. Вы можете разместить контроллеры где угодно, но если они расположены в другой сборке, вам потребуется реализовать собственную фабрику контроллеров, которая знает, как их найти. Вот пример расположения ваших контроллеров с помощью Windsor.
Ваши модели / модели просмотра могут быть где угодно. Вам просто нужно сослаться на их пространство имен в web.config, чтобы представления знали, где искать. (По крайней мере, я знаю, что это правда с движком просмотра Spark.)
Вы размещаете свои взгляды в любом веб-проекте. Моя обычная стратегия - создать простой веб-проект (не mvc), содержащий папку представлений. (Это может быть даже устаревшее веб-приложение!) Тогда все мои контроллеры помещаются в отдельную библиотеку классов. На мой взгляд модели и сервисы уходят в другое.
Что касается структурирования папок, я обычно сосредотачиваю свою иерархию вокруг концепций домена. В каждом проекте у меня была бы папка для пользователей, продуктов, заказов и т. Д. У меня никогда не было папки "Модели" или "Контроллеры".
Вам необходимо использовать переносные зоны, см. http://www.lostechies.com/blogs/hex/archive/2009/11/02/asp-net-mvc-portable-areas-part-2.aspx