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