Model-View-Controller (Модель-Представление-Контроллер) – это шаблон (паттерн) проектирования, который, как и все прочие шаблоны проектирования, появился не “из неоткуда”, а в результате анализа поведения объектов реального мира. В контексте данного шаблона модель (Model) - это не что иное, как модель некой предметной области или отдельного ее фрагмента. Контроллер (Controller) – абстракция, воздействующая на модель и представляющая результат своего воздействия в виде представления (View). К примеру, когда вы являетесь в какой-нибудь государственный орган за какой-нибудь важной справкой, то вы взаимодействуете с некой базой знаний (модель) через сотрудника - оператора (а иногда эта должность так и называется - контролёр), и результатом этого взаимодействия является справка – то самое представление, отражающее нужную вам часть знаний из общей базы знаний. То же самое происходит и в магазине, где контроллер – это продавец, модель – магазин, представление – товар. Таким образом, не стоит зацикливаться на том, что представление – это аналог отчета. Представление – это любой результат воздействия контроллера на модель. Контроллер – это посредник, который знает, чего хочет пользователь, и как это запросить у модели. Именно этого принципа и нужно придерживаться, когда вы проектируете свои предложения.

На первый взгляд вроде бы все просто, но это лишь на первый взгляд. Причины неэффективного использования паттерна MVC - это некорректное, с точки зрения его концепции, распределение функциональности между тремя компонентами этого паттерна. Точнее будет сказать так: эффективность применения шаблона проектирования Model-View-Controller напрямую зависит от правильного разделения (баланса) ответственности между всеми участниками взаимодействия: между пользователем, контроллером, моделью и представлением. Приведу еще один пример из жизни, который должен помочь “визуализировать” правильное разделение ответственности между моделью, контроллером и представлением. Итак, модель – это правила дорожного движения (ПДД), пользователь – водитель, контроллер – сотрудник ГИБДД, представление – штраф, как мера наказания за нарушение ПДД. Как только в ПДД попадают нормы и положения, которые могут применяться выборочно на усмотрение сотрудника ГИБДД в одной и той же сложившейся ситуации (применить либо выговор, либо штраф, либо лишение прав), так сразу функции модели частично переходят к контроллеру, что является грубым нарушением концепции. Контроллер не должен ничего “решать сам” – он должен быть посредником между пользователем и моделью! В нашем примере, в случае, если возникла неопределенность, эту неопределенность должен разрешить суд – отдельный и независимый компонент модели!

Достаточно часто при разработке архитектуры приложения в соответствии с концепцией Model-View-Controller, в качестве модели называют уровень приложения работы с данными. Не уровень так называемой бизнес логики приложения, а именно уровень работы с данными, который взаимодействует с хранилищем данных на языке базовых терминов, структур и операций, определенных природой этого хранилища. В случае реляционной базы данных это таблицы, поля, записи, транзакции, связи и т.п. Соответственно, бизнес логика приложения частично переносится на уровень контроллера или что еще хуже – на уровень представления.

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




Почему нельзя размещать бизнес логику приложения на уровне контроллера? Потому что требования к системе могут содержать требования к различным режимам его функционирования: в режиме авторизованного пользователя или в режиме анонимного пользователя. Если приложение коммерческое, то логика его работы может также зависеть от того, платным или бесплатным является аккаунт текущего пользователя. Для каждого из таких режимов иногда целесообразно создавать отдельные наборы контроллеров, а не нагружать одни и те же контроллеры разветвленной логикой авторизации.

Итого:

Модель – это абстракция, которая моделирует объекты предметной области, связи между объектами, логику (если угодно, законы) взаимодействия объектов между собой и т.п. сущности, отвечающие за качество и полноту информационного моделирования.

Контроллер – посредник, между запросом пользователя и моделью. Контроллер отвечает за интерпретацию запроса пользователя, его корректный перевод на язык модели, формирование запроса к модели и передачи результата запроса на уровень представления!

Представление – ответная часть запроса. Представление ответственно за трансформацию результата запроса к модели в ту форму, которую будет способен интерпретировать пользователь с учетом природы клиентской части приложения (веб-приложение, настольное или мобильное приложение).