ASP.NET Структура Проекта MVC для более крупных сайтов
«Композиция объектов Favour по сравнению с наследованием классов» на самом деле из книги GoF. Этот разговор с Эрихом Гаммой описывает эту идею из книги.
Одним важным шаблоном, который требует наследования, является шаблон шаблонного метода. Этот шаблон широко используется очень удобно, поэтому наследование здесь, чтобы остаться. Другим распространенным шаблоном, который использует наследование, является шаблон Composite. Суть, которую я пытаюсь подчеркнуть, заключается в том, что вообще не стоит сбрасывать со счетов наследование, но я надеюсь, что это все равно ясно, если взглянуть на столько распространенных API-интерфейсов ...
3 ответа
Посмотрите на Области .
Области - это концепция, заимствованная из MonoRail, которая организует контроллеры в логические папки.
http://haacked.com/archive/2008/11/04/areas-in-aspnetmvc.aspx
Области поддерживаются в Asp.Net MVC2.
Скотт Гу ведет блог, в котором говорится о поддержке области здесь .
Из его сообщения.
Каждая область может быть реализована как отдельный проект ASP.NET MVC, который может затем на него будет ссылаться основная заявление. Это помогает управлять сложность при строительстве большого приложение и облегчает несколько команды, работающие вместе над единым приложение вместе
Я всегда удаляю папку «модели» и ссылаюсь на отдельные библиотеки классов, которые представляют мои уровни бизнес-логики и уровни доступа к данным. У меня также есть некоторые решения, в которых мои контроллеры хранятся в отдельных проектах от моих представлений. Я согласен с тем, что для более крупных приложений модель единого проекта не подходит. Даже в небольших приложениях, особенно там, где код модели должен использоваться совместно с другими приложениями, размещение классов моделей в реальном проекте MVC - плохая идея.