В чем разница между ViewModel и контроллером?

ViewModel — это шаблон, используемый для обработки логики представления и состояния представления, а контроллер — одна из основных частей любой структуры MVC, он отвечает на любой HTTP-запрос и организует все последующие действия до http-ответа.

Шаблон ViewModel: Подробнее

В шаблоне ViewModel пользовательский интерфейс и любая логика пользовательского интерфейса инкапсулированы в представление. View наблюдает за ViewModel, которая инкапсулирует логику представления и состояние. ViewModel, в свою очередь, взаимодействует с Model и действует как посредник между ней и View.

View <-> ViewModel <-> Model

Контроллеры (из шаблона переднего контроллера): Подробнее

Он «обеспечивает централизованную точку входа для обработки запросов».

HTTP Request -> Controller -> (Model,View)

--Простые отличия:--

• Хотя ViewModel является необязательным шаблоном, контроллер является обязательным, если вы идете по пути MVC.
• ViewModel инкапсулирует логику представления и состояние, а контроллер организует весь поток приложений.

• ViewModel может быть как на стороне клиента, так и на стороне сервера. Где бы это ни было, единственной целью модели просмотра является воспроизведение данных презентации.
• В архитектуре MVC Viewmodel не является обязательным, но без контроллера запрос от клиента не может быть обработан.
• Контроллер можно представить как основной интерфейс между клиентом и сервером для получения любого ответа от сервера. Он обрабатывает запрос клиента, извлекает данные из репозитория, а затем подготавливает данные представления. Модель представления можно визуализировать как обработчик/представитель данных представления, таким образом, интерфейс для более красноречивого управления представлением.
• В общем контексте веб-приложения мы можем сказать, что контроллер — это обработчик запросов приложения, тогда как модель представления — это только обработчик пользовательского интерфейса.

Model-View-Controller (MVC) — это шаблон архитектурного проектирования, который существует, прежде всего, для отделения бизнес-логики от представления. По сути, вы не хотите, чтобы задняя часть касалась передней части. Обычно это выглядит так:

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

Простой пример того, где пригодится MVC — допустим, у вас есть приложение, которое управляет финансами вашей компании. Теперь, если вы правильно используете MVC, у вас может быть внешний интерфейс, который сидит за столом какого-нибудь финансиста и позволяет ему обрабатывать транзакции, управлять финансами и т. д. НО, поскольку бизнес-логика является отдельной, вы также можете предоставить внешний интерфейс. на Blackberry вашего генерального директора, который позволяет ему видеть текущее состояние бизнеса. Поскольку два внешних интерфейса разные, они могут выполнять разные действия, при этом предоставляя (разные типы) доступ к данным.

ИЗМЕНИТЬ:

Поскольку вы немного обновили свой вопрос, я обновлю свой ответ. Нет идеальной науки для разделения MVC. Однако есть несколько хороших эмпирических правил. Например, если вы говорите о компонентах графического интерфейса, это, вероятно, представление. (Вы говорите о внешнем виде, удобстве использования и т. д.) Если вы говорите о данных и «деловой» стороне дома (базы данных, логика и т. д.), вы, вероятно, имеете в виду модель. И все, что контролирует взаимодействие между ними, скорее всего, является контроллером.

Кроме того, следует отметить, что хотя представления и модели обычно «физически» разделены, контроллер может существовать с представлением, когда это имеет смысл.

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

Надеюсь, это поможет!

Для генерации некоторых данных (структурированных или полуструктурированных) необходимо вызвать некоторую логику и модель. Из этих данных возвращается страница /JSON/etc. создается, как правило, только с рудиментарной логикой.

Первая часть (создание данных) выполняется контроллером (обычно через модель). Вторая часть - Видом. ViewModel — это структура данных, которая передается между контроллером и представлением и обычно содержит только средства доступа.

Я думаю, есть некоторая ценность в изучении принятого учения. Но также важно понять, как учение стало таким, какое оно есть.

Трюгве Реенскаугу широко приписывают изобретение MVC. Статья Н. Алекса Руппа За пределами MVC: новый взгляд на архитектура сервлета включает историю MVC. В разделе, посвященном работе Реенскауга в 1978 году в Исследовательском центре Xerox в Пало-Альто, есть ссылка на его статью Thing-Model-View-Editor: пример из системы планирования. Там куски описаны так.

Вещь

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

Модель

Модель — это активное представление абстракции в виде данных в вычислительной системе.

Просмотреть

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

Редактор

Редактор — это интерфейс между пользователем и одним или несколькими представлениями. Он предоставляет пользователю подходящую систему команд, например, в виде меню, которые могут динамически изменяться в соответствии с текущим контекстом. Он предоставляет представлениям необходимую координацию и командные сообщения.

Рупп идентифицирует редактор Reenskaug как контроллер или инструмент.

Триады MVC появились в SmallTalk-80. Модель была абстракцией концепции реального мира, представление было его визуальным представлением, а контроллер представлял собой кнопки и ползунки, которые позволяли пользователю взаимодействовать с ним (тем самым «управляя» представлением). Все части в триаде были взаимосвязаны и могли общаться с двумя другими частями, так что не было никакого наслоения или абстракции. С тех пор Reenskaug «предпочитает использовать термин «Инструмент», а не «Контроллер». Согласно его заметкам, это термины, которые он использовал в более поздних реализациях.

Модель представляет ваши данные и то, как ими манипулируют. Таким образом, модель касается БД.

Вид — это ваш пользовательский интерфейс.

Контроллер является связующим звеном между ними.

MVC означает Модель, Представление, Контроллер.

Модель = Данные (таблицы базы данных)

Вид = HTML, CSS, JavaScript и т. д.

Контроллер = основная логика, контракт между моделью и представлением.

Говоря простым и понятным языком,

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