Подтвердить что ты не робот

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

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

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

При использовании фиксированных папок Controller, Model и View в вашем ASP.NET MVC вы фактически создаете огромный кусок вещей. Разве что разделение проблем, действительно? Похоже на меня, наоборот.

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

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

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

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

Ответ 3

Разделение кода на отдельные сборки является ортогональным для разделения проблем. Там, где живет код, это не "проблема". Разделение проблем связано с обязанностями и направлением зависимостей различных компонентов. Например, Views несут ответственность за визуализацию вывода, а контроллер знает о представлениях, но представления на самом деле не имеют непосредственного знания о контроллере.

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

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

Ответ 4

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

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

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

Что касается структурирования папок, я обычно сосредотачиваю свою иерархию на понятиях домена. У меня будет папка в каждом проекте для "Пользователи", "Продукты", "Заказы" и т.д. У меня никогда не было папки "Модели" или "Контроллеры".