LINUX.ORG.RU

Проблемы с MVC в современных приложениях.

 ,


0

1

Призадумался я над такой вот проблемой. Как мы можем полноценно реализовать концепцию MVC веб приложений, оставаясь в пределах одного языка или фреймверка? Ведь, фактически, наше приложение размазано между клиентом и сервером. Например, очевидно, что вид логичней всего реализовывать на клиентской стороне. Что касается модели и контроллера, то все не так однозначно. Например, клиент нажимает на кнопку. Должен ли об этом нажатии что-то знать вид? Сомневаюсь. Логично, что это нажатие слушает контроллер. Значит что, контроллер тоже на клиенте? Но как мы будем тогда на сервере диспетчеризовать запросы? Значит что получается: контроллер у нас размазан между клиентом и сервером. Примерно те же самые проблемы возникают и с моделью, например, нужно достать данные из кэша или тянуть их с сервера? модель значит должна быть и на клиенте. Нужно как то абстрагировать это различие, нужен слой абстракции. А как мы его обеспечим, если клиентская и серверная сторона на разных языках и технологиях?

Все это усугубляется еще и появлением вебсокетов, когда сервер сам может становится клиентом, а клиент — сервером.

Тут напрашивается решение в лоб: писать отдельный язык, который скроет детали различий между клиентской и серверной стороной. Или множество контроллеров и моделей по обеим сторонам, которые проксируют друг другу запросы? Еще варианты?



Последнее исправление: linearisation (всего исправлений: 3)

Логично, что это нажатие слушает контроллер. Значит что, контроллер тоже на клиенте?

Логично

сходи еще раз на курс по логике

unt1tled ★★★★
()
Ответ на: комментарий от unt1tled

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

Что сказать-то хотел?

linearisation
() автор топика

Веб-приложение - это 2 приложения, фронтенд и бэкенд.

tailgunner ★★★★★
()

man изоморфные приложения

Kilte ★★★★★
()

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

Kilte ★★★★★
()
Ответ на: комментарий от linearisation

А еще контроллер предоставляет данные из модели во вью. По крайней мере в spring. А spring, как мы знаем, эталон веб разработки.

Вьюха (оно же frontend) это макакоформачке. Остальное — бекэнд и то, что можно назвать программированием без истеричной улыбки.

unt1tled ★★★★
()
Ответ на: комментарий от unt1tled

А еще контроллер предоставляет данные из модели во вью

если говорить о канонической реализации — то нет:

Активная модель — модель оповещает о произошедших в ней изменениях те представления, которые подписались на получение таких оповещений. Это позволяет сохранить независимость модели от контроллеров и представлений.

Классической реализацией концепции MVC принято считать версию именно с активной моделью.

как мы знаем

кто это, «вы»?

Только я не понял, какое отношение это все имеет к твоему первоначальному возражению, по поводу того, что контроллер слушает юзеринпут?

linearisation
() автор топика

Как мы можем полноценно реализовать концепцию MVC веб приложений, оставаясь в пределах *одного языка или фреймверка*?

А зачем? Фронтенд и бакенд хорошо отделены по времени и месту обитания. Бакенду фронтенд - просто резултат его работы, отдан клиенту, фронтенду бакенд - совсем неактуальная сущность, которая его породила и ушла.

PHPFan
()

Нет никаких проблем. Бекенд и фронтенд - 2 разных приложения. И их можно написать с использованием паттерна MVC. Да, по отдельности.

Hater ★★
()
Ответ на: комментарий от Hater

Нет никаких проблем. Бекенд и фронтенд - 2 разных приложения. И их можно написать с использованием паттерна MVC. Да, по отдельности.

Поддерживаю сего оратора

gwinn ★★★★
()
Последнее исправление: gwinn (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.