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

Ответ 1

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

Шаблон ViewModel: Дополнительная информация

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

View <-> ViewModel <-> Model

Контроллеры (поступают из шаблона переднего контроллера): Дополнительная информация

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

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

- Обычные различия: -

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

Ответ 2

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

Ответ 3

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

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

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

EDIT:

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

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

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

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

Ответ 4

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

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

Ответ 5

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

Trygve Reenskaug широко приписывают изобретение MVC. Статья N. Alex Rupp Помимо MVC: новый взгляд на архитектуру сервисов включает в себя историю MVC. В разделе, посвященном работе Reenskaug 1978 в Исследовательском центре Xerox Palo Alto, есть ссылка на его статью Thing-Model-View-Editor: пример из системы plannings. Там фрагменты описываются следующим образом.

Вещь

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

Model

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

Просмотр

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

Редактор

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

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

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

Ответ 6

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

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

Контроллер - это клей между ними.

Ответ 7

MVC означает Model, View, Controller.

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

Просмотр = HTML, CSS, JavaScript и т.д.

Controller = Основная логика, контракт между Model и View.

В простых и понятных терминах

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