Client-MVC vs server-MVC

Ответ 1

Преимущества сервера MVC:

• Зрелые.
• Широко принят.
• Большая часть кода находится внутри сервера, поэтому должна быть более безопасной.

Но определенно тенденция заключается в возврате к клиент-серверным вычислениям, но вместо толстых клиентов, написанных на C или другом языке, но теперь у вас очень хорошая платформа: браузер.

У меня есть простая политика, когда я использую MVC на стороне сервера и MVC на стороне клиента:

• Случайные пользователи с небольшим количеством взаимодействий: Server + Ajax.
• Приложение LOB (Бухгалтерия, ERP, CRM и т.д.): Клиент.

BTW Я использую Java Server Faces для # 1 и ExtJS, которые поддерживаются службами JAX-RS для # 2.

С уважением.

Ответ 2

Как я вижу это, MVC на стороне сервера остается актуальным, если вы рассматриваете V как свою клиентскую сторону MVC, завернутую в черный ящик. Дело в том, что речь идет о сотрудничестве и масштабируемости. Сервер MVC на стороне сервера продолжает подпитывать API REST (например) с понятием, что вы технически передаете технологию просмотра в отдельную инфраструктуру, работающую в вашем браузере.

Поскольку браузер все чаще рассматривается как платформа разработки приложений, вы можете экспортировать огромные объемы данных с вашей "бэкэнд-платформы" на клиента (браузер), а затем обрабатывать данные как локальную "базу данных" в своем браузере, что позволяет быстро отклика,

Объединение этих двух структур MVC позволяет:

• Разреженный трафик между сервером и клиентом, тем самым уменьшая задержку
• Повышенная отзывчивость ваших веб-приложений путем локализации доступа к более релевантным наборам данных
• Распределение нагрузки с одного серверного контроллера на сотни браузеров

Архитектура здесь очень похожа на CDN - сети доставки контента! На самом деле речь идет о локализации данных и приближении их к процессинговым центрам.

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

Ответ 3

Ну, вам все равно понадобится исходная страница, которая может обслуживаться серверным MVC-движком.

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

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

Ответ 4

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

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

Реальный и более важный вопрос: сторона клиента и рендеринг стороны сервера? Где вы хотите создавать свои HTML-представления, на сервере или на клиенте? Это другой вопрос, который больше беспокоит скорость страницы и отзывчивость пользовательского интерфейса. Кроме того, он был ответен несколько раз в нескольких местах. Поиск ex: https://stackoverflow.com/search?q=client+rendering+vs+server+rendering

Ответ 5

Я думаю, что MVC - отличный образец для простых веб-приложений. Однако это не помогает при создании современных и богатых веб-приложений, таких как Facebook или Gmail. Взгляните на это сообщение по нескольким причинам, почему бы не использовать MVC:

http://dennis-nerush.blogspot.co.il/2016/04/should-we-use-mvc-for-modern-web.html