Как создать ViewModel в MVVM для не нарушения Единственного Принципа Ответственности?
Я согласен с предыдущим комментарием, что вы можете рассмотреть возможность использования списка параметров. Тем не менее, вы также можете использовать форсирующую функцию или механизм событий.
Страницы справки можно найти в deSolve:
«события принуждения»
и краткое руководство здесь: https://tpetzoldt.github.io/deSolve-forcing/deSolve -forcing.html
4 ответа
Единственная ответственность ViewModel состоит в том, чтобы предоставить Представлению информацию, в которой это нуждается. Если для Представления нужны различные и несвязанные свойства, который не важен, поскольку ViewModel только имеет одну причину измениться, и это - Представление, показывающее различные свойства. Таким образом, Вы не должны волноваться слишком много.
Тем не менее, если ViewModel действительно становится огромным, возможно, Вы могли бы думать о делении представления в несколько подпредставлений улучшать возможность многократного использования и сохранять Представления и ViewModels управляемыми.
Да, но это не означает, что плохой дизайн не мог вынудить Вас в него.
Я соглашаюсь с gcores.
После того как Вы видите, что ViewModel растет больше чем до двух screenfuls текста, пора считать разделение ViewModel в несколько дочерних моделей.
Другое эмпирическое правило - то, что у меня никогда нет больше чем двух уровней вложения в файле XAML - если одна часть представления становится слишком сложной, время для рефакторинга представления - извлекают внутренний XAML в отдельный UserControl и создают соответствующий ViewModel, который будет контекстом данных по умолчанию на дочернем представлении.
Я согласен с тем, что разделение ваших экранов на несколько представлений с несколькими моделями представления необходимо для уменьшения раздувания и сложности. Вот еще один шаблон, который я использовал, чтобы помочь придерживаться SRP с помощью MVVM:
Вот один сценарий. Моя модель просмотра должна получать данные и отвечать на команды фильтрации из пользовательского интерфейса. Я создаю ViewModel как составную по структуре. То есть дочерние классы, которые имеют доступ к закрытым членам ViewModel, выполняют линейные задачи, такие как обработка фильтрации. У меня также может быть другой дочерний класс, который выполняет необходимую логику для выбора элементов на основе критериев. Вы уловили идею. Когда ViewModel выполняет определенные функции, охватывающие несколько методов, она может быть хорошим кандидатом для делегирования дочернему классу. Дочерние классы остаются частью основной ViewModel, так что это просто способ уменьшить размер ViewModel и упростить модульное тестирование этих линейных операций.