Все это зависит от намерения и требований вашего приложения.

Тем не менее, вот мое предложение для «средних масштабов» (не местный ресторан и не Twitter/Facebook) веб-приложений.

1. Бережливое моделирование домена

   Сухие объекты в стиле POCO, желательно не знающие архитектуры MVC вашего веб-приложения, чтобы оставаться как можно более слабо связанными с вашей конкретной реализацией. ).

   «Модель» в MVC наиболее точно означает модель, о которой знает контроллер и, следовательно, модель, предназначенную для представления.

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

   В более крупных приложениях разработчики часто используют принципы архитектуры MVVM и начинают использовать отдельные объекты модели представления. Контроллеры часто вызывают службы среднего уровня, которые работают с невидимыми сущностями ниже. В этом сценарии буква M в MVC наиболее точно означает модель представления.

2. Надежный сервисный уровень

   Это означает не ожиревшую логику, а хорошо написанные одноцелевые сервисы. Хотя кодирование вашей бизнес-логики в службах за пределами модели немного более «процедурно», чем в чистом «ООП», оно очень помогает при слабой связи, тестировании и гибком развертывании (например, развертывании n-уровневого).

   В моей личной практике я кодирую сервисы как на уровне данных, что я считаю своим поведенческим моделированием объектов POCO (механика постоянства, низкоуровневая проверка и т. д.), так и сервисы более высокого уровня (функция бизнес-процесса) ближе к механика MVC.

3. Бережливые контроллеры

   Я удостоверяюсь, что мой контроллер — это просто тренер, в том смысле, что он не является ни play (сервисами), ни player (моделью сущности или моделью представления). ), а просто решает, кто и какую позицию играет. Мои контроллеры делают две вещи:

   1. Службы вызовов, взаимодействующие с моделями объектов/доменов.

   2. Подготовьте модель представления для соответствующего представления.

   Даже аутентифицированные/авторизованные действия контроллера выполняются с помощью внедренных сервисов/атрибутов.

ИЗМЕНИТЬ 1:

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

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

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

РЕДАКТИРОВАТЬ 2:

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

ИЗМЕНИТЬ 3:

Я хотел бы отметить, что это объяснение и совет относятся к контексту серверной архитектуры MVC, такой как ASP.Net, а не к клиентским платформам, таким как Knockout или Backbone.

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

Узор очень слабо определен. Ничто не говорит о том, как должен выглядеть контроллер, представление или модель или как они должны быть структурированы. Шаблон просто указывает, что вы должны разделить части и то, как они должны взаимодействовать друг с другом. Итак, давайте посмотрим на то, что они из себя представляют (моя интерпретация).

МВК

Модель Модель может быть любой. Это может быть веб-сервис, ваши репозитории, ваши классы обслуживания или просто ваши модели предметной области. Модель — это все, что используется для получения необходимой информации. Рассматривайте «Модель» как слой, а не как отдельный объект.

Контроллер Контроллер — это связующее звено. Он берет информацию из модели и адаптирует ее к представлению и наоборот.

Вид В представлении должно отображаться только то, что видит пользователь.

Обратите внимание, что не следует путать модель с моделями просмотра. Microsoft действительно должна была назвать папку «Модель» «ViewModels», так как это то, чем они являются. Я бы не стал использовать информацию из "Модели" напрямую в представлениях. Невыполнение этого требования будет означать, что вам придется изменить модель, если изменится представление, и наоборот.

Ответ

Модель - это не модель представления, а слой. Все в модели используется для получения информации, необходимой для представления. Контроллер берет эту информацию и помещает ее в единую модель представления.

Одно действие контроллера может использовать один или несколько вызовов «Модели», чтобы собрать информацию, необходимую для представления.

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

Обратите внимание, что сервисный уровень может не понадобиться. Вы можете вызвать OR/M непосредственно с контроллеров. Но если вы обнаружите, что дублируете код или получаете толстые контроллеры, просто переместите логику на сервисный уровень. Это изменение не повлияет ни на что, кроме контроллера, поскольку вы используете правильные модели представления.

Вариант 1: Можно подумать, что модель == сервис. Модель также ЯВЛЯЕТСЯ бизнес-уровнем.

Вариант 2 — это антишаблон модели предметной области Anemic. http://en.wikipedia.org/wiki/Anemic_domain_model

Вариант 2 описывается как архитектура Fat Stupid Ugly Controllers (Ссылка на автора этого выражения). Это решение, как правило, противоречит духу MVC, поскольку нарушает разделение задач.