Почему использование MVVM?

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

В MVVM есть много хороших вещей, но, возможно, самое важное - это возможность тестировать ваш код (модульное тестирование ViewModels).

Отсутствие связи между представлением и моделью представления также помогает ослабить связь. Очень легко повторно использовать компоненты, которые вы кодируете.

Из статьи Джоша Смита о MVVM :

В дополнение к функциям WPF (и Silverlight 2), которые делают MVVM естественным способом структурирования { {1}} шаблон также популярен, потому что классы ViewModel легко поддаются модульному тестированию. Когда логика взаимодействия приложения находится в наборе классов ViewModel, вы можете легко написать код, который ее проверяет. В смысле представления и модульные тесты - это всего лишь два разных типа потребителей ViewModel . Наличие набора тестов для моделей представления приложения обеспечивает бесплатное и быстрое регрессионное тестирование , которое помогает снизить затраты на обслуживание приложения с течением времени.

Для меня это самая важная причина использовать MVVM.

Раньше у меня были элементы управления, которые совмещали представление и модель представления вместе. Но представление, по сути, имеет события мыши и клавиатуры в качестве ввода и нарисованные пиксели в качестве вывода. Как вы проводите модульное тестирование чего-то в этом роде? MVVM решает эту проблему, поскольку он отделяет непроверяемое представление от тестируемой модели представления и сохраняет уровень представления как можно более тонким.

Ознакомьтесь с введением в MVVM в этой статье

В 2005 году Джон Госсман, в настоящее время один из архитекторов WPF и Silverlight в Microsoft, представил шаблон Model-View-ViewModel (MVVM) в своем блоге. MVVM идентична модели представления Фаулера в том, что оба шаблона содержат абстракцию представления, которая содержит состояние и поведение представления. Фаулер представил модель представления как средство создания независимой от платформы пользовательского интерфейса абстракции представления, тогда как Госсман представил MVVM как стандартизованный способ использования основных функций WPF для упрощения создания пользовательских интерфейсов. В этом смысле я считаю MVVM специализацией более общего шаблона PM, специально созданной для платформ WPF и Silverlight.

..

В отличие от Presenter в MVP, ViewModel не требует ссылки на представление. Представление привязывается к свойствам модели представления, которая, в свою очередь, предоставляет данные, содержащиеся в объектах модели, и другое состояние, специфичное для представления. Привязки между представлением и ViewModel легко построить, потому что объект ViewModel установлен как DataContext представления. Если значения свойств в ViewModel изменяются, эти новые значения автоматически передаются в представление через привязку данных.Когда пользователь нажимает кнопку в представлении, на ViewModel выполняется команда для выполнения запрошенного действия. ViewModel, а не View, выполняет все изменения, внесенные в данные модели. Классы представления не знают, что классы модели существуют, в то время как ViewModel и модель не знают о представлении. Фактически, модель полностью игнорирует тот факт, что ViewModel и представление существуют. Это очень слабо связанный дизайн, который приносит дивиденды во многих отношениях, как вы скоро увидите.

Также в статье объясняется, почему следует использовать эти графические шаблоны:

Нет необходимости и контрпродуктивно использовать шаблоны проектирования в простом "Hello, World!" программа. Любой грамотный разработчик сразу поймет несколько строк кода. Однако по мере увеличения количества функций в программе количество строк кода и движущихся частей соответственно увеличивается. В конце концов, сложность системы и повторяющиеся проблемы, которые она содержит, побуждают разработчиков организовывать свой код таким образом, чтобы его было легче понять, обсудить, расширить и устранить неполадки. Мы уменьшаем когнитивный хаос сложной системы, применяя известные имена к определенным объектам в исходном коде. Мы определяем имя, которое следует применить к фрагменту кода, учитывая его функциональную роль в системе.

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

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

1. Я активно использую RelayCommand из MVVM Foundation Джоша Смита. Это делает привязку от View к ViewModel через команды намного чище.

2. Я использую АОП, чтобы облегчить боль при реализации INotifyPropertyChanged. В настоящее время я использую Postsharp, хотя считаю, что есть и другие инструменты, которые могут это сделать. Если бы я этого не обнаружил, я бы, наверное, уже сдался, так как шаблонный код для его реализации вручную действительно меня раздражал.

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

   • Это то, что я умею делать

   • Это то, что мне нужно было сделать

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

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

Чтобы ответить на вопрос об INotifyPropertyChanged через Postsharp, я использую аспект, основанный на примере здесь . Я немного настроил его для себя, но это дает вам суть. При этом я просто помечаю класс [NotifyPropertyChanged], и все общедоступные свойства будут иметь шаблон, реализованный в их установщиках (даже если они устанавливают автоматические свойства). Мне это кажется намного чище, так как мне больше не нужно беспокоиться о том, хочу ли я тратить время на то, чтобы класс реализовал INotifyPropertyChanged.Я могу просто добавить атрибут и покончить с этим.

Из здесь :

Почему вы, как разработчик, должны даже заботиться о шаблон Модель-Представление-ViewModel ? Этот шаблон дает ряд преимуществ для разработки как WPF, так и Silverlight. Прежде чем продолжить, спросите себя:

• Вам нужно поделиться проектом с проектировщик, и у вас есть гибкость для проектирования и разработки, которые должны выполняться почти одновременно?
• Требуется ли вам тщательное модульное тестирование ваших решений?
• Насколько важно для вас иметь повторно используемые компоненты как внутри, так и в проектах в вашей организации?
• Хотели бы вы большей гибкости, чтобы изменить свой пользовательский интерфейс без необходимости рефакторинга другой логики в кодовая база?

Если вы ответили "да" на любой из этих вопросов, это лишь некоторые из преимуществ, которые может {{1} использовать модель MVVM }} принесите для вашего проекта.

В конечном итоге вы будете счастливы, если будете использовать такой шаблон, как MVVM, по всем причинам, опубликованным другими. Помните, что вам не нужно дословно следовать требованиям шаблона, просто убедитесь, что у вас есть хорошее разделение между вашим окном (View) и вашей логикой (code-behind).

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

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

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

Например, если вы правильно следуете MVVM, вы должны иметь возможность вносить очень радикальные изменения в логику отображения, например заменять все представление, без влияния на данные и бизнес-логику.

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