Выбор паттерна для работы с WPF - CodeHelper

Выбор паттерна для работы с WPF

2

Какой design pattern выбрать для работы с WPF. Наиболее популярные варианты — это MVP (Model-View-Presenter), PM (Presentation Model) и MVVM (Mode-View-ViewModel). Какие преимущества и недостатки этих шаблонов в контексте WPF?

Лучший ответ:

1

Вот неплохо описана ответственность ViewModel:

Модель определена так же, как и в MVC; это данные или бизнес-логика, полностью независимые от UI, которые хранят и изменяют свое внутреннее состояние (хз, как прально перевести "does the processing of the problem domain"). Модель полностью описана кодом или представлена чистыми данными в виде взаимосвязаных таблиц или XML-данных.

Вид в концепции MVVM состоит из визуальных элементов, кнопок там, окошек всяких, графических элементов и более сложных элементов GUI. Он обрабатывает нажатия клавиш, да и вообще занимается взаимодействием с внешними устройствами ввода данных, что является областью ответственности контроллера в MVC (то, что действительно произошло с контроллером в современной разработке GUI - это отдельный и непростой вопрос... я предпочитаю думать, что он отступил на задний план. Контроллер в том виде, что описан в концепции MVC по-прежнему существует, однако играет уже совсем не такую значимую роль, как то было в 1979 году). Вид сейчас почти всегда объявляется декларативно, очень часто при помощи какой-то специализированной утилиты. Из-за особенностей таких утилит и вообще декларативного стиля некоторые состояния вида, которые MVC легко хранит в присущих ей классах видов, непросто реализовать. Например, UI может иметь множественные состояния, такие как "режим просмотра" и "режим редактирования", которые влияют на поведение визуальных элементов или на сам их вид, однако эти состояния не всегда можно выразить только лишь в виде XAML разметки (хотя и существует такая клевая штука, как триггеры).

Вот тут и вступает в игру привязка данных. В простых примерах вид привязывается непосредственно к модели. Часть ее просто отображается в виде путем однонаправленной привязки данных. Другие части модели могут быть отредактированы путем двунаправленной привязки контролов вида к данным модели. Например, свойства типа Boolean в модели могут быть привязаны к CheckBox'ам, или строковые поля - к TextBox'ам.

Новые ответы


2

продолжение:

Однако, на практике только небольшое подмножество UI приложений может быть напрямую связано с данными модели, особенно если модель представляет собой уже существующий класс или данные, над которыми разработчик не имеет контроля. Также модель может включать в себя такие типы данных, которые не могут быть прямо отражены в виде. UI может потребоваться произвести некие сложные операции, которые должны быть реализованы в коде (не в XAML), который, с одной стороны, не может принадлежать виду (т.к. мы его определяем как весьма легковесную сущность), а с другой стороны слишком специфичен для включения в модель (возможно, вовсе нет возможности для его включения в модель, т.к. она представляет собой неизменяемую сущность). В итоге нам нужно место, куда можно было бы поместить некоторые подобные вещи. За эти задачи отвечает ViewModel. Этот термин должен трактоваться как "Модель над абстрактным видом" (Model of a View). Он подразумевает собой абстракцию над видом, однако так же реализует некоторые вещи, слишком специфичные для модели (вид может пользоваться ими для привязки). Другими словами ViewModel может содержать в себе некоторые механизмы преобразования типов модели в типы вида, а так же содержать команды, которые вид может использовать для влияния на модель.

Взято вот отсюда


v1.7.123.556
© 2009—2010 CodeHelper FAQ | О сайте | Обратная связь | История изменений | Статьи
Creative Commons LicenseМатериалы сайта распространяются под лицензией Creative Commons Attribution-Share Alike 3.0 Unported.