Блог

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

Какие уникальные преимущества я получаю от использования MVVM, которые я не могу получить ни от каких других реализаций? MVC. NTiers или что-нибудь еще. На самом деле я не ищу отличительные особенности, которые отличают MVVM. Я ищу то, что невозможно сделать ни в чем другом, кроме MVVM. Мои текущие знания об этом наводят меня на мысль, что MVVM — это другой способ сделать то же самое, который вносит больше сложности, чем, скажем, nTiers. Я не хочу считать, что введение этой сложности является негативным моментом. Если это оправдано включением уникальных преимуществ, то я хотел бы это знать.

Углубленный поиск в Google обнаружил только защиты MVVM. В нем не было этих уникальных преимуществ.

Единственное преимущество, о котором я могу думать, специфичное для шаблона MVVM поверх MVP (вариантом которого он является), заключается в том, что в MVVM вам не нужно явно привязывать представление к ViewModel (Presenter), как это было бы в реализации MVP. Это возможно благодаря возможностям, предоставляемым WPF. (Наиболее важные выражения привязки) В MVP вы бы определили интерфейс, который представляет, как presenter может взаимодействовать с view (IxxxxView — это обычный шаблон именования), и когда вы создаете свой presenter, вы передаете ему интерфейс view (который прикреплен к экземпляру view). Это также допускает некоторые варианты представления поверх обычного презентатора.

В MVVM вы явно не определяете этот интерфейс. Вы определяете свою ViewModel и используете привязку для подключения ViewModel (логики) к представлению (презентации). В представлении нет встроенных знаний о ViewModel, поскольку привязки (если они выполнены в XAML) разрешаются во время выполнения (или иногда в конструкторе). Теоретически, приложение WPF должно быть способно работать полностью без пользовательского интерфейса.

Преимущество, которое вы получаете от MVVM / MVP / MVC, в первую очередь заключается в разделении задач между представлением и бизнес-логикой и в том, что это позволяет. Это позволяет специально подготовленным ролям (читай: настоящим графическим дизайнерам) работать над презентацией, не имея никаких знаний о коде C # / VB.NET. С их помощью можно создать презентацию, а разработчики придут и все подключат впоследствии.

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

На самом деле это не касается сравнения между «N-Tier» и MVVM, хотя, потому что я не знаю, является ли это сравнением яблок с яблоками. Возможно, приложения MVVM WPF — это N-уровневые приложения с несколькими логическими уровнями в решении.

В конечном счете, MVVM / MVP / MVC — это все очень сопоставимые шаблоны с одинаковыми преимуществами. Однако есть одна вещь, которая заключается в том, что MVVM, каким я его знаю, может использоваться только тогда, когда WPF / Silverlight является предпочтительной технологией представления. И я думаю, что это единственное преимущество MVVM. Это специфичный и оптимальный шаблон для нас в WPF / Silverlight. После использования MVVM было бы неудобно использовать любой другой шаблон в WPF.

MVVM — это всего лишь крошечный поворот в шаблоне класса «Модель-представление-презентатор». Единственное отличие от MVVM заключается в том, что ваши классы ‘view-model’ разработаны специально для того, чтобы хорошо взаимодействовать с функциями привязки данных, встроенными в WPF и Silverlight, чтобы свести к минимуму необходимость в любом коде в самом представлении (сохраняя представление исключительно разметкой XAML, которую можно редактировать / заменять в конструкторе). Если вы используете WPF или Silverlight, на это определенно стоит обратить пристальное внимание. Если вы используете что-то другое, это на самом деле неприменимо.

MVVM — это всего лишь технологически специфичная реализация шаблона модели представления.

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

Над этими двумя задачами могут даже работать параллельно два разных человека, используя разные инструменты (например, Visual Studio против Выражение).

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

Вот статья о фреймворке Java, использующем MVVM («модель представления»), MVP («пассивный просмотр») и гибрид MVVMP / MVC («контролирующий контроллер»). Я думаю, что это имеет отношение к вопросу, поскольку в нем сравниваются шаблоны, и наблюдение за тем, как это делается за пределами WPF, может помочь в формировании мнения относительно того, что такое шаблон, что такое фреймворк и каковы варианты и силы при попытке использовать шаблоны проектирования GUI, управляемые событиями.

Реализация шаблонов графического интерфейса, управляемых событиями, с использованием ZK Java AJAX framework

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