Связывание данных принципиально несовместимо с MVC?

Question

Привязка данных устанавливает прямую связь между представлением и моделью, тем самым обходя контроллер.По сути, это противоречит архитектурному шаблону Model-View Controller. Правильно ли я считаю это?Делает ли это связывание данных «плохой вещью»?

Редактировать: Например, angular претендует на то, чтобы быть фреймворком MVC, но одна из его основных функций - данныепереплет.

Answer 1

Не обязательно, поскольку вам не нужно привязывать объекты Model к представлению.
Обычно я создаю простые DTO (или объекты презентаций), которые содержат только данные, которые я хочу отображать, и вот чтоотображается слой View.
В этом случае Контроллер сохраняет свою функцию переводчика между действиями, выполняемыми над DTO, и действиями с базовыми объектами Model.

Answer 2

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

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

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

ОБНОВЛЕНИЕ

Но в оригинальном смысле шаблона я бы охарактеризовал привязку данных больше как MVP или Пассивное представление .

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

Answer 3

Привязка данных напрямую не связывает вид и модель, поэтому это не Bad Thing ®. Это неотъемлемая особенность архитектуры MVC, которую книга GoF Design Patterns кратко описывает в главе 1.

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

Распространено заблуждение, что MVC является многоуровневой (3-уровневой) архитектурой. Это не. Модель обновляет представление напрямую. Но это не значит, что они связаны! Дизайн публикации / подписки сохраняет связь между моделью и представлением.

Этот более общий дизайн описывается шаблоном Observer .

Answer 4

На самом деле, когда ваши данные абстрагированы должным образом, процесс отправки содержимого ваших моделей в ваш пользовательский интерфейс является повторяющейся задачей, которая обычно приводит к каким-то «помощникам».

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

Также здесь вы повторяете себя (подумайте о СУХОЙ) и делаете одно и то же снова и снова.

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

Взгляните на mvc & databinding: каков наилучший подход? .Здесь я обсуждаю, что может быть оптимальным при использовании привязки данных в сочетании с MVC.