MVVM та схема обслуговування

Я будую додаток WPF за допомогою шаблону MVVM. Зараз мої viewmodels викликають сервісний шар для отримання моделей (як це не стосується viewmodel) та перетворення їх у viewmodels. Я використовую інжектор конструктора, щоб передати необхідну послугу в перегляд.

Це легко перевіряється і добре працює для моделей перегляду з невеликими залежностями, але як тільки я намагаюся створити viewModels для складних моделей, у мене є конструктор, що в нього вводиться багато служб (один для отримання кожної залежності та список усіх доступних значень наприклад, для прив’язки до itemsSource). Мені цікаво, як обробляти кілька подібних служб, і все ще є перегляд моделей, який я можу легко виконати.

Я думаю про кілька рішень:

1. Створення сервісу одиночного типу (IServices), що містить усі доступні сервіси як інтерфейси. Приклад: Services.Current.XXXService.Retrieve (), Services.Current.YYYService.Retrieve (). Таким чином, у мене немає величезного конструктора з тоннами параметрів послуг.

2. Створення фасаду для служб, які використовує viewModel, і передача цього об'єкта в ctor моєї viewmodel. Але тоді мені доведеться створити фасад для кожного з моїх складних моделей перегляду, і це може бути трохи більше ...

Як ви вважаєте, що це "правильний" спосіб втілення подібного роду архітектури?

Насправді обидва ці рішення погані.

Створення сервісу одиночного типу (IServices), що містить усі доступні сервіси як інтерфейси. Приклад: Services.Current.XXXService.Retrieve (), Services.Current.YYYService.Retrieve (). Таким чином, у мене немає величезного конструктора з тоннами параметрів послуг.

Це, по суті, Шаблон локатора послуг , який є антитілом. Якщо ви це зробите, ви більше не зможете зрозуміти, від чого насправді залежить модель перегляду, не дивлячись на його приватну реалізацію, що ускладнить тестування або рефактор.

Створення фасаду для служб, які використовує viewModel, і передача цього об'єкта в ctor моєї viewmodel. Але тоді мені доведеться створити фасад для кожного з моїх складних моделей перегляду, і це може бути трохи більше ...

Це не стільки антидіаграма, але це кодовий запах. По суті, ви створюєте об'єкт параметрів , але суть шаблону рефакторингу PO полягає в тому, щоб мати справу з наборами параметрів, які використовуються часто і в багатьох різних місцях , тоді як цей параметр буде використовуватися лише один раз. Як ви вже згадували, це створило б багато розширення коду без жодної реальної користі, і не було б чудово грати з великою кількістю контейнерів IoC.

Насправді обидві вищевказані стратегії ігнорують загальну проблему, яка полягає в тому, що зв’язок занадто високий між моделями перегляду та послугами . Просте приховування цих залежностей у службовому локаторі чи об'єкті параметрів фактично не змінює, скільки інших об'єктів залежить від моделі перегляду.

Подумайте, як би ви провели тестування однієї з цих моделей перегляду. Наскільки великим буде ваш код налаштування? Скільки речей потрібно ініціалізувати, щоб воно працювало?

Багато людей, починаючи з MVVM, намагаються створити моделі перегляду для цілого екрану , що принципово неправильний підхід. MVVM стосується композиції , і екран з багатьма функціями повинен складатися з декількох різних моделей перегляду, кожна з яких залежить лише від однієї або декількох внутрішніх моделей / послуг. Якщо їм потрібно спілкуватися між собою, ви робите це через pub / sub (брокер повідомлень, шина подій тощо)

Насправді вам потрібно зробити рефакторинг моделей перегляду, щоб вони мали менше залежностей . Потім, якщо вам потрібно мати сукупний "екран", ви створюєте іншу модель подання для об'єднання менших моделей перегляду. Ця модель сукупного вигляду не повинна робити багато сама по собі, тому вона, в свою чергу, також досить проста для розуміння та тестування.

Якщо ви зробили це правильно, це повинно бути очевидним лише з огляду на код, оскільки у вас будуть короткі, стислі, конкретні та перевірені моделі.

Я міг би написати про це книгу ... насправді я є;)

По-перше, не існує універсально "правильного" способу робити речі. Ви повинні враховувати інші фактори.

Можливо, ваші послуги занадто дрібнозернисті. Обгортання Служб фасадами, які надають інтерфейс, який використовує конкретний Viewmodel або навіть кластер пов'язаних ViewModels, може бути кращим рішенням.

Ще простіше було б обернути сервіси в єдиний Фасад, який використовують усі переглядачі. Звичайно, це потенційно може бути дуже великим інтерфейсом з великою кількістю непотрібних функцій для середнього сценарію. Але я б сказав, що це не відрізняється від маршрутизатора повідомлень, який обробляє кожне повідомлення у вашій системі.

Насправді те, що я бачив у багатьох архітектурах, в кінцевому підсумку еволюціонує, - це шина повідомлень, побудована навколо чогось подібного до шаблону агрегатора подій. Тестування там легко, оскільки ваш тестовий клас просто реєструє слухача з EA і запускає відповідну подію у відповідь. Але це попередній сценарій, на який потрібен час, щоб вирости. Я кажу, починайте з об'єднувального фасаду та йдіть звідти.

Чому б не поєднати обидва?

Створіть фасад та розмістіть усі сервіси, якими користуються ваші представники. Тоді ви можете мати єдиний фасад для всіх своїх моделей без поганого слова S.

Або ви можете використовувати введення властивостей замість конструктора. Але тоді вам потрібно переконатися, що ті отримують ін'єкцію належним чином.