MVVM
От: Flem1234  
Дата: 21.12.19 09:37
Оценка:
Всем привет.

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

Сейчас все организовано как MVVM:
Представления для интерфейса
Классы разных сервисов для управления ими и получения от них событий.
Вью модель, которая сейчас занята в основном согласованостью своего состояния. Например, если пользователь выбрал какой-то элемент, то ему доступно то или другое, а третье не доступно.

Пытаясь упростить вью модели (они и так достаточно сложные), я выношу логику в дополнительные классы, которые используют и классы модели и класс вью модели. Например, пользователь нажал кнопку. Я должен поставить значение вью модели, дергнуть пару сервисов и по окончанию их работы восстановить значение из вью модели. Дополнительно, для обработки событий от внешних сервисов, приходится создавать дополнительные классы, основная работа которых среагировать на событие от сервиса, запросить еще данных от вью модели, вызвать пару сервисов, обновить вью модель.

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

В сторону каких паттернов посмотреть, бест практики там, подходы, и т.п.?
Re: MVVM
От: Буравчик Россия  
Дата: 21.12.19 13:15
Оценка: 2 (1)
Здравствуйте, Flem1234, Вы писали:

F>Вью модель, которая сейчас занята в основном согласованостью своего состояния. Например, если пользователь выбрал какой-то элемент, то ему доступно то или другое, а третье не доступно.


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

F>Пытаясь упростить вью модели (они и так достаточно сложные), я выношу логику в дополнительные классы, которые используют и классы модели и класс вью модели. Например, пользователь нажал кнопку. Я должен поставить значение вью модели, дергнуть пару сервисов и по окончанию их работы восстановить значение из вью модели. Дополнительно, для обработки событий от внешних сервисов, приходится создавать дополнительные классы, основная работа которых среагировать на событие от сервиса, запросить еще данных от вью модели, вызвать пару сервисов, обновить вью модель.

F>В принципе, все получается нормально, но хочется как-то унифицировать (в любом смысле) классы, которые обрабатывают действия пользователя и реагируют на события сервисов.

Все правильно делаешь. Для унификации всю логику приложения (полезная работа) нужно вынести в дополнительные классы — команды. Вся работа приложения должна идти только через эти команды. Пользователь нажал кнопку — вызвал команду, сообщил пользователю результат. Поступило событие от внешнего сервиса — вызвал команду.

Общий код команд выделяешь в отдельные классы, которые используются командами совместно, и, возможно, делаешь иерархию команд.
Best regards, Буравчик
Re: MVVM
От: ylem  
Дата: 24.12.19 21:48
Оценка:
F>В сторону каких паттернов посмотреть, бест практики там, подходы, и т.п.?

Может будет полезно:
У нас кроме команд были "сценарии" (формально, скорее поведения). Они слушали события и что-нибудь делали с моделью и/или вью-модель.
Некоторые жили всегда и были, можно сказать, без состояния.
Некоторые запускались на время какого-то действа, у них были состояния. Логику переходов последних очень удобно и явно программить через await-async: стэйт-машин за вас сделает компилятор.

MVVM там был особенный, без байндингов, но, наверное, это не много меняет.
Re: MVVM
От: varenikAA  
Дата: 25.12.19 01:20
Оценка:
Здравствуйте, Flem1234, Вы писали:


F>В сторону каких паттернов посмотреть, бест практики там, подходы, и т.п.?


https://reactiveui.net/docs/getting-started/
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re: MVVM
От: alexanderfedin США http://alexander-fedin.pixels.com/
Дата: 15.02.20 05:56
Оценка:
Здравствуйте, Flem1234, Вы писали:

F>В принципе, все получается нормально, но хочется как-то унифицировать (в любом смысле) классы, которые обрабатывают действия пользователя и реагируют на события сервисов.


F>В сторону каких паттернов посмотреть, бест практики там, подходы, и т.п.?

У меня ощущение от описанного, что у вас MVVM крупными кусками, из-за чего и приходится делать какие-то дополнительные классы, не особо ложащиеся в MVVM парадигму. Я бы посоветовал выделить более мелкие составляющие в виде MVVM элементов.
Пример: если у тебя в UI есть MVVM для всего заказа, то было бы неплохо иметь MVVM компоненты для адреса получателя, для секции элементов заказа, для персональной информации о получателе. Секцию элементов заказа строить из MVVM компонентов «строка элемента заказа», и так далее.
Тогда ты сможешь собирать сколь угодно большой и сложный UI из отдельных кирпичиков.
Respectfully,
Alexander Fedin.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.