Как построить ViewModel в MVVM, чтобы не нарушать принцип единой ответственности? - PullRequest
12 голосов
/ 28 февраля 2009

Роберт Мартин говорит: «Не должно быть более одной причины для изменения класса» .

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

Должны ли мы беспокоиться о принципе SRP в случае класса ViewModel или нет?

Ответы [ 4 ]

19 голосов
/ 28 февраля 2009

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

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

2 голосов
/ 28 февраля 2009

Я согласен с Gcores.

Как только вы увидите, что ViewModel увеличится до более чем двух экранных текстов, пришло время рассмотреть разделение ViewModel на несколько дочерних моделей.

Другое эмпирическое правило заключается в том, что у меня никогда не бывает более двух уровней вложенности в файле XAML - если одна часть представления становится слишком сложной, настало время для рефакторинга представления - извлеките внутренний XAML в отдельный UserControl и создайте соответствующий ViewModel, который будет контекстом данных по умолчанию для дочернего представления.

0 голосов
/ 22 марта 2010

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

Вот один сценарий. Моя ViewModel должна получать данные и отвечать на команды фильтра из пользовательского интерфейса. Я создаю ViewModel, чтобы быть составной по структуре. То есть дочерние классы, которые имеют доступ к закрытым членам ViewModel, выполняют линейные задачи, такие как обработка фильтрации. У меня также может быть другой дочерний класс, который выполняет необходимую логику для выбора элементов на основе критериев. Вы поняли идею. Как только ViewModel выполняет определенные функции, охватывающие несколько методов, он может стать хорошим кандидатом для делегирования дочернему классу. Дочерние классы остаются частью основной ViewModel, поэтому это всего лишь способ уменьшить размер ViewModel и упростить модульное тестирование этих линейных операций.

0 голосов
/ 28 февраля 2009

Да, но это не значит, что плохой дизайн не может заставить вас в этом.

...