Посмотрев на следующую диаграмму (которая объясняет MVC), я вижу однонаправленный поток данных.
Итак, почему мы рассматриваем MVC для двунаправленного потока данных при обосновании потока?
MVC против Flux? Двунаправленный против однонаправленного?
Ответ 1
Потому что в фреймворках Javascript MVC не работает так, как вы изображали. Пользовательский интерфейс, как правило, передается в двух направлениях с моделью, например:
- Типы пользователей во вход View
- Структура MVC связывает onchange(), чтобы обновить модель.
- Запрос Ajax содержит новые данные модели.
- Обновления среды MVC Просмотр входного значения для соответствия модели.
В архитектуре Flux пользовательский интерфейс только запускает независимое действие с типом и связанными данными с диспетчером, который затем обновляет модель так же, как любой фоновой метод ajax будет обновлять модель.
Ссылка: http://www.thesoftwaresimpleton.com/blog/2013/03/23/client-side-mvc/
"Клиентская сторона MVC полностью отличается от MVC на стороне сервера"
"Мы создаем двухстороннюю связь между двумя объектами..."
"Короче говоря, мы соединяем значение свойства firstName объекта Person к значению свойства ввода."
http://guides.emberjs.com/v1.10.0/object-model/bindings/
привязки в Ember.js могут использоваться с любым объектом не только между просмотров и моделей.
Ответ 2
Реальный и чистый MVC является однонаправленным. Это видно из диаграммы википедии, вставленной в вопрос.
Более десяти лет назад, когда серверные структуры, такие как Apache Struts, реализовали вариант MVC, называемый моделью View Viewenter (MVP), каждый запрос проходил через контроллер, и каждый ответ возвращался через контроллер. Все продолжали называть его MVC. Из-за присущего веб-сайта любые изменения в модели не могут быть переданы в представление без просмотра отправки запроса или обновления. Таким образом, Pure MVC не реализован. Скорее MVP реализован.
Несколько лет назад, когда фреймворки, такие как Angular, Ember, Knockout реализовали MVC на переднем конце, они реализовали другой вариант MVC с именем Model View ViewModel (MVVM), несколько человек продолжали называть его MVC. (и немногие поняли, что терминология не важна и называется MVW (W означает Whatever)), ни один из них не реализовал чистый MVC.
Когда React родился, они воспользовались возможностью реализовать чистый MVC (не MVP или MVVM) и переименовали его как Flux с небольшими изменениями. Я чувствую, что Flux - еще один вариант MVC. Хотя команда Flux/React говорит, что это не MVC, я вижу много четности между обеими архитектурами - Flux и MVC.
Ответ 3
Я встроенный разработчик, и я использую шаблон MVC в своем приложении. Мое приложение очень мало, и я настроил свою архитектуру как почти однонаправленный MVC. Но я прочитал эту статью, объясняя MVC на стороне клиента, и некоторые мысли о различиях между MVC и FLUX.
Ссылка: http://www.christianalfoni.com/articles/2015_08_02_Why-we-are-doing-MVC-and-FLUX-wrong
Традиционный MVC
|------| request |------------| request |-------|
| | ---------> | | ---------> | |
| VIEW | response | | response | |
| | <--------- | | <--------- | |
|------| | | | |
| CONTROLLER | | MODEL |
|------| request | | request | |
| | ---------> | | ---------> | |
| VIEW | response | | response | |
| | <--------- | | <--------- | |
|------| |------------| |-------|
ПОТОКА
COMPONENTS ACTION CREATORS STORES
|----------------------<<<<-------------------|
| |
|------| |------------| |-------|
| | request | | request | |
| VIEW | ---------> | | ---------> | MODEL |----
| | | | | | |
|------| | | |-------| |
| CONTROLLER | |
|------| | | |-------| |
| | request | | request | | |
| VIEW | ---------> | | ---------> | MODEL | |
| | | | | | |
|------| |------------| |-------| |
| | | |
| |--------------------<<<<-------------------| |
|----------------------<<<<----------------------------|
Ответ 4
Некоторые люди приняли термин MVC для обозначения фреймворков JavaScript, которые другие указали, что не были чистыми MVC, но были вариацией, которая могла бы быть называемый MVP (Магистраль), MVVM (Angular 1) или более широко MV * (также см. ответ Аруна).
Когда Facebook представил Flux, они сравнили его с проблемами с MVVM/MVP/MV *, но смутно использовал термин MVC.
Для чистых разработчиков MVC, наблюдающих за этим видео, Facebook заявил, что проблемы с MVC не имеют смысла, а описание Facebook Flux было ближе к MVC, чем система MVVM, которую они описали:
Основная проблема заключается в том, что они неправильно выполняли MVC. Затем они исправили его, но решили перекрасить его и сказать, что изобрели схему развязки данных, просмотра и обработки событий.
Похоже, ваши программисты создали поток, потому что они не знали, как правильно использовать MVC и диспетчеров событий.