Как создать ViewModel в MVVM, чтобы не нарушать принцип единой ответственности?

Роберт Мартин говорит: "Для класса не должно быть более одной причины" .

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

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

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

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