Пояснення МВВМ

Ми збираємось написати нашу першу заявку на WPF та ознайомимось із схемою MVVM. Ми створили багато додатків Winform та має архітектуру, яка була дуже успішною для нас. У нас виникають невеликі проблеми з перекладом цієї архітектури або визначенням того, де певні фрагменти нашої архітектури вписуються в модель MVVM.

Історично у нас є Gui (головний exe), який потім повідомляє dll BusinessLogic. BusinessLogic спілкується з DAL dll через веб-сервіс і DAL взаємодіє з БД. DAL, BusinessLogic та GUI всі посилаються на один і той же dll BusinessObjects.

AsIs Architecture

Деякі з переходів до MVVM є досить прямими. Наш Gui все ще буде містити погляди, наші BusinessOjbects все ще будуть містити модель, а наш DAL все ще буде взаємодіяти з БД (хоча технологія їх впровадження може змінитися).

У чому ми не впевнені, це наш компонент BusinessLogic. Історично це забезпечило б функції GUI для виклику, а потім заповнити елементи управління у видах (тобто. GetCustomerList, який повертає список об'єктів клієнта або типові функції CRUD).

Основна робота, яку ми маємо, - чи буде модель MVVM закликати додатковий компонент для розміщення ViewModels або якщо ми просто змінимо своє мислення та перемістимо те, що ми використовували як наш компонент BusinessLogic, до ViewModels?

Чи представляє наш компонент BusinessLogic ViewModels?

architecture mvvm

— user7676
джерело

Це звучить трохи як рішення, яке шукає проблему. Чи є вагома причина, чому ви переходите до MVVM? Я шанувальник цього шаблону, але ваше попереднє рішення не працювало? Модель перегляду - це як наглядний ведучий. Він містить логіку презентації та поверхневі дані через прив'язку даних. Він повинен знати про вашу бізнес-логіку і мати можливість досягти цього рівня, але я б не зруйнував бізнес-логіку в самій моделі перегляду.

— Jeremy Likness

Відповіді:

Взагалі я б не розміщував бізнес-логіку в шарі перегляду моделі. Але термін "Бізнес-логіка" вводить в оману.

Ерік Еванс використовує модель, де ділова логіка ділиться на дві категорії

Логіка домену - логіка, пов'язана з фактичною проблемою, яку ви вирішуєте
Логіка програми - Логіка, пов'язана з тим, що ви будуєте додаток

Він наводить приклад програми бухгалтерського обліку. Правила щодо рахунків, постів, податкових рахунків тощо - це доменні правила, правила, що стосуються галузі обліку. Логіка щодо імпорту / експорту CSV не має нічого спільного з областю обліку. Ці правила існують лише тому, що ми будуємо програмне забезпечення. Це приклади логіки програми.

Правила домену НІКОЛИ не повинні переходити в шар моделі перегляду. Якщо ви слідуєте за шаблоном MVVM, правила домену переходять, без сумнівів, у шарі моделі.

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

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

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

— Піт
джерело

Відмінна відповідь. Мені подобається переконатися, що ViewModel містить лише логіку презентації. Чи можете ви додати будь-яке посилання, пов’язане з вашим пунктом Еріка Еванса?

— користувач7676

Я сумніваюся, що я можу знайти посилання, тому що я вважаю, що я отримав це з його книги «Дизайн, керований доменом». У будь-якому випадку, я думаю, що це відмінний приклад різниці між логікою домену та додатків. Більше про книгу тут books.google.dk/books/about/…

— Піт

Так.

Шар бізнес-логіки представлений шаром VM. Тому просто мігруйте свою ментальну модель.

Щоб допомогти з міграцією вашої ментальної моделі, один незначний нюанс полягає в тому, що об’єкти GUI (View) повинні бути прив’язані до об'єктів всередині VM-шару. Це зв'язування перекладається на | Мається на увазі, що Перегляд більше не є тим шаром, який "робить виклик", щоб отримати щось інше. Виклик для отримання даних буде надходити замість ВМ.

Для кращого пояснення: Так, об’єкт у Перегляді потрібно змінити, щоб запустити послідовність речей, які здійснюватимуть виклик. Але Перегляд не робить дзвінок сам по собі. І в цьому випадку я вважаю натискання кнопки рівнозначним тому, що відбувається в межах Перегляду, що змінюється, але все ще не робить дзвінка.

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

У другому випадку (подія натискання кнопки) подія зміни (натискання) може бути підключена до виклику функції, що піддається ВМ.

У будь-якому випадку, це завжди подія, яка послідовно переходить у VM, яка потім викликає модель, яка в свою чергу викликає DAL / DB.

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

Дякуємо за підтвердження. Ми розуміємо нюанс того, як View взаємодіє з ViewModel, і будемо триматись до моделі прив’язки та відмовлятись від "дзвінка".

— користувач7676

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

— user7676

Я погоджуюся, що рівень бізнес-логіки представлений шаром VM, проте, я думаю, частини вашої відповіді можуть бути заплутаними. Цей Viewшар повинен бути візуальним поданням ViewModel або Model, тому замість того, щоб сказати, що подія клацання підключена до виклику функції на VM, кращим визначенням буде сказати, що команда у ВМ виводиться як кнопка в шар Перегляд. Крім того , я звичайно не люблю мій шар моделі в змозі отримати доступ до DAL безпосередньо, тому мій потік додатку, як правило , йде VM -> DAL -> DB, де VMі DALобидва використовують прості Modelоб'єкти даних.

— Рейчел

Я не згоден з цією відповіддю. ViewModel - модель представлення, вона містить логіку перегляду, а не ділову логіку. ViewModels є частиною шару презентації

— simoraman

@simoraman - Шаблон MVPVM узгоджується з тим, що ви пропонуєте. Я думаю, що MVPVM - хороший зразок, але трохи важкий для менших додатків. Я б дуже попросив вас поставити свої думки у відповідь і сприяти цьому питанню.

Ви впевнені, що фактично замінюєте dll BusinessLogic своїм шаром ViewModel, проте, я думаю, що найбільша різниця, з якою ви зіткнетеся, полягає в тому, як шар View / UI взаємодіє з вашим шаром ViewModel / BusinessLogic.

У WinForms графічний інтерфейс є вашим додатком і відповідає за потік додатків. У WPF / MVVM, ваш ViewModels - це ви програма, і GUI стає просто зручним інтерфейсом для взаємодії з ViewModels.

Наприклад, за допомогою WinForms у вас можуть бути DataGrid та кнопка, а при натисканні на цю кнопку ви викликаєте BusinessLogicLayer.GetProducts()та завантажуєте отримані об’єкти продукту в DataGrid.

З WPF ви мали б ViewModel, який містить і ObservableCollection<Products>і ICommand GetProducts, і виконання команди викликає DAL і завантажує колекцію продуктів. Але щоб забезпечити для цього зручний інтерфейс, ви створили б представлення, яке відображає ваш ViewModel, використовуючи DataGrid для колекції продуктів, і кнопку для команди GetProducts.

Насправді я написав досить недавній пост для свого блогу про зміну настрою при переході від Winforms до WPF в своєму блозі , і я вважаю, що найкращий спосіб узагальнити різницю - це за допомогою цих фотографій:

— Рейчел
джерело

Я погоджуюся з GlenH7, це хороша відповідь для тих, хто починає роботу з WPF. Ми отримуємо зсув парадигми взаємодії між View і ViewModel, так що це насправді не було темою до питання, яке я задав.

— user7676