Структура проекта MVC 3

Question

Я пытаюсь найти лучший способ компоновки моего проекта MVC 3.При поиске в Интернете я наткнулся на предложение, которое, в основном, гласило: щелкните правой кнопкой мыши на проекте и добавьте область.Это позволило создать папку области с такой же структурой контроллер / вид / модель в том же проекте.Это не то, что я хочу.Я хочу гибкости иметь отдельные проекты.Я буду хранить только представления в основном веб-проекте.Все остальное в отдельном проекте.

К этой попытке я создал отдельный проект для своих контроллеров.Теперь я застрял с указанием действия контроллера на представление.Во всех онлайн-примерах это был щелчок правой кнопкой мыши и добавление вида.Это проект библиотеки классов, у меня нет такой гибкости. Где я ошибаюсь?

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

Каковы ваши мысли, советы по этому поводу?

Спасибо за ваше время ...

Answer 1

MVC основан на соглашении; соглашение заключается в том, что вы помещаете все представления в / views, модели в / models и контроллеры в / controllers. Вы можете изменить соглашение, но это не облегчит вашу жизнь.

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

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

Answer 2

Не понимаю, почему вы не можете использовать встроенные генераторы в качестве основы для ваших представлений и контроллеров?Ничто не говорит о том, что вы должны оставить их как порожденные.Лично я считаю, что это действительно хорошо - создать базу для меня (с помощью щелчков мышью).

Проект MVC - это просто слой пользовательского интерфейса.Это безумие - вкладывать в это логику для крупномасштабных приложений.Поэтому обычно хорошо иметь один проект для всего пользовательского интерфейса.Это на самом деле облегчает получение обзора пользовательского интерфейса.

Тем не менее, есть способы получить решение на основе плагинов, где вы можете перемещать контроллеры (модели и представления) в библиотеки классов.Но это не легко.

1. Вам необходимо создать провайдера виртуального пути (чтобы найти представления)
2. Сделать все представления встроенными
3. Изменить файл проекта, чтобы получить «Добавить представление»диалоговое окно и т. д.
4. Использование областей (упрощает)
5. Сообщите BuildManager, что DLL вашего плагина существует.

Вам также необходимо изменить виртуальный путьпровайдер для доступа к представлениям из ваших папок плагинов, если вы хотите иметь возможность изменять представления во время выполнения в Visual Studio.В противном случае любое изменение потребует перестройки плагина DLL.

Обновление

Видео для MVC2 (области MVC3 работают одинаково): http://www.asp.net/mvc/videos/mvc-2/how-do-i/aspnet-mvc-2-areas

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

Answer 3

Зачем хранить только ваши взгляды в «основном веб-проекте» - я думаю, что вы упускаете из виду MVC.

Это контроллеры, которые являются вашей "основной сетью". Это то, что пользователи запрашивают и отправляют обратно, а не представление.

Представление предназначено только для предоставления макета HTML, который контроллер может передать в браузер.

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

Итак, вы можете видеть, что макет MVC действительно хочет, чтобы все три из них были разумно сгруппированы вместе. Контроллеры взаимодействуют с вашим пользователем, получают представление (макет) и заполняют его вашей ViewModel / Model (данные). Это ваш пользовательский интерфейс, все три части MVC (если вы все равно используете ViewModel) предназначены только для пользовательского интерфейса.

Откуда поступают данные, ваши реальные модели и все, что вы хотите с ними сделать, могут легко находиться в dll где-то или на другой стороне набора веб-сервисов или чего-то еще.