Как организовать MVC на клиенте?

Question

[pavelbazhan]

Есть задача - создать SPA-приложение придерживаясь паттерна MVC. По сути, приложение должно только забирать данные с удаленного сервера при помощи определенного API (сам сервер нам недоступен, разрабатываем только клиентскую часть).

С сервером, казалось бы, все понятно — он принимает GET-запрос, как-то его там обрабатывает, обращается к собственной БД, достает оттуда данные и отправляет назад. В таком случае, насколько я понял — моделью является БД, контроллером является некий скрипт, который обрабатывает мой запрос, а представление — это ответ с сервера в виде JSON, к примеру.

А вот как дела обстоят на клиенте? Получается, моя HTML-страничка — это представление. Контроллер представлен клиентскими JS-скриптами, которые асинхронно обращаются к удаленному серверу и получают оттуда данные. А вот что такое модель для клиента? Мне приходит в голову только то, что моделью для клиента является весь удаленный сервер целиком, вместе с контроллером и представлением. Ведь для нашего JS-скрипта существует только некий черный ящик в виде сервера, к которому мы обращаемся по адресу. Устройства удаленного ресурса мы не знаем, поэтому и делить на составные части его не можем.

Так ли это или я просто запутался?

Answer 1

[xmoonlight]

Предлагаю вспомнить, как выглядит MVC-схема:

Модель (model) - это объект(ы), куда попали данные после парсинга ответа от серверного API.
Контроллер (controller) - это логика взаимодействия объектов (логические связи, механика).
Представление (view) - это непосредственный вывод на экран (рендеринг/отображение).

Answer 2

[Дмитрий]

Все примерно так, контроллером в данном случае является сервер
Можно конечно назвать единицу данных, получаемых с сервера моделью, но если вы ничего с ней не делаете, а лишь держите в состоянии и выводите во вьюшщку, то назвать ее можно хоть соленым огурцом.

Другое дело, что если на клиенте с ней сотворяется CRUD и при сотворении CRUD-а применяется какая-то логика, то да, появляются модель и контроллер. (например список работников, который выводится, создается новый работник и редактируются существующие)

Answer 3

[Ilya Pavlov]

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

Если вы уже решили, что у вас будет SPA(Single Page Application), то скорее всего(в большинстве случаев) и M, и V, и C будут у вас в SPA.

Например:
M - это данные бизнес логики вашего приложения(Инфа о пользователе, товарах, постах, контенте), иными словами - все те данные, которые имеют значение не для текущего клиента, а для всего продукта в целом. Такие вещи обычно суют в Redux, MobX или аналоги. Также существуют данные, необходимые для конкретного клиента, например информация о том, открыто ли боковое меню приложения. Такие данные нужно хранить отдельно от основной модели. Например в стейте React компонентов.
V - это представление(view) вашего пользовательского интерфеса. V - это просто штука, которая рисует интерфес на основе M. Как правило это обычно React, Vue (частично Angular).
С - Это логика взаимодействия с приложением через пользовательский интерфес. Для React это например может быть реализовано с помощью Thunk, Saga, но может выходить и за их пределы. C в процессе обработки пользовательских действий может обновлять M, выполняя запросы к API сервера.

И сам сервер, и его API не имеют отношения к MVC клиента. Да и вообще в принципе(ссылаясь на википедию) не должны иметь отношения к MVC.

Архитектура серверной части и все что там происходит - это уже отдельная задача, и судя по вашему вопросу даже не ваша.

Я так осторожно ссылаюсь на википедию, потому что существуют например PHP фреймворки, которые также используют терминологию MVC. Но тут нужно понимать, что там это немного другое, так как при использовании PHP фреймвороков, часто интерфейс генерируется прямо на сервере. И соответственно они и называют некоторые вещи V и используют "MVC" "на сервере".