ASP.NET MVC - разделение большого приложения

Question

Я был озадачен тем, что считаю противоречием в терминах: ASP.NET MVC утверждает, что он продвигает и поддерживает девиз "разделения интересов", который я считаю отличной идеей.

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

С фиксированными папками Controller, Model и View в ASP.NET MVC вы фактически создаете огромную кучу вещей. Это разделение интересов, правда? Мне кажется, что это совсем наоборот.

Так что мне интересно:

• как я могу создать решение ASP.NET MVC, которое будет разделять контроллеры, модель и папки с полными представлениями на отдельные сборки?

• как разместить области ASP.NET MVC 2 в отдельных сборках?

• или как еще вы управляете большим приложением ASP.NET MVC, которое имеет несколько десятков или даже более ста контроллеров, множество классов моделей и моделей представления и несколько сотен представлений?

Answer 1

Я думаю, что вы ищете Области в ASP.Net MVC 2 . Есть некоторые вещи, которые нужно раскомментировать в файлах CSProj, но после этого он скопирует представления при сборке. Я не думаю, что существует какое-либо требование, чтобы классы Controller или Model находились в той же сборке, что и представления.

Пошаговое руководство. Создание приложения ASP.NET MVC Areas областей с использованием нескольких проектов

Answer 2

Контроллеры: AFAIK Вам не нужно делать ничего особенного, чтобы выбросить контроллеры в их собственную сборку. Самое большее, что вам нужно сделать, это переопределить метод GetControllerType вашего ControllerFactory.

Модели: Ноль ограничений на то, где вы размещаете свои модели. Хотя это неодобрительно, я регулярно использую постоянные объекты из DTO уровня Nhibernate / другого или DTO уровня WCF / сервиса, которые расположены в отдельной сборке как мои представления. Это работает так же, как при использовании WebForms .

Представления: Представления в отдельной сборке должны быть помечены как встроенный ресурс, а затем вы должны использовать пользовательский VirtualPathProvider , который знает, как получить представления из ресурса вместо файла система. просмотров из ресурса вместо файловой системы . Опять же, это точно такой же метод, который вы бы использовали для разработки WebForm.

Относительно mcintyre321 и его ответа Portable Areas: Связанный проект делает только что-то нестандартное и просто объединяет существующие точки расширения MVC 2 в более простую в использовании абстракцию. Её «нестандартный» и более синтаксический сахар.

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

Answer 3

Разделение кода на отдельные сборки ортогонально разделению задач. Где живет код, не является «проблемой». Разделение интересов связано с обязанностями и направлением зависимостей различных компонентов. Например, представления отвечают за рендеринг вывода, и контроллер знает о представлениях, но представления на самом деле не имеют глубоких знаний о контроллере.

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

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

Answer 4

MVC очень расширяем и не требует соблюдения структуры папок Controller, View и Model. Вы можете разместить контроллеры где угодно, но если они расположены в другой сборке, вам потребуется реализовать собственную фабрику контроллеров, которая знает, как их найти. Здесь - пример расположения ваших контроллеров с помощью Windsor.

Ваши модели / модели просмотра могут быть где угодно. Вам просто нужно сослаться на их пространство имен в web.config, чтобы представления знали, где искать. (По крайней мере, я знаю, что это верно для движка Spark View.)

Вы размещаете свои взгляды в любом веб-проекте. Моя обычная стратегия - создать простой веб-проект (не mvc), содержащий папку представлений. (Это может быть даже устаревшее веб-приложение!) Тогда все мои контроллеры помещаются в отдельную библиотеку классов. На мой взгляд модели и сервисы уходят в другое.

Что касается структурирования папок, я обычно сосредотачиваю свою иерархию вокруг концепций домена. В каждом проекте у меня была бы папка для пользователей, продуктов, заказов и т. Д. У меня никогда не было папки с моделями или контроллерами.

Answer 5

Вам необходимо использовать переносные участки, см. http://www.lostechies.com/blogs/hex/archive/2009/11/02/asp-net-mvc-portable-areas-part-2.aspx