За яких умов використання MVVM доцільно?

Model View View-Model була розроблена корпорацією Майкрософт для орієнтації на платформи розробки інтерфейсу, які підтримують керовані подіями програмування, зокрема Windows Presentation Foundation (WPF) та Silverlight на платформах .NET, використовуючи мови XAML та .NET. За роки, коли багато рамок Javascript, таких як Angular, Knockout та ExtJS, прийняли цей зразок.

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

MVVM призначений для використання там, де потрібні складні взаємодії користувачів, що використовують високоточний інтерфейс користувача (наприклад, WPF ).

MVVM орієнтований на сучасні платформи розробки користувальницького інтерфейсу (Windows Presentation Foundation, або WPF та Silverlight), в яких існує розробник досвіду користувача (UXi), який має вимоги, відмінні від вимог більш «традиційного» розробника (наприклад, орієнтованого на бізнес-логіку та розвиток заднього кінця). Модель View MVVM є "в основному перетворювачем значень на стероїдах", тобто, що View-Model відповідає за викриття об'єктів даних із Моделі таким чином, що цими об'єктами легко керувати та споживати. У цьому відношенні View-Model є більше моделлю, ніж View, і обробляє більшість, якщо не всю логіку відображення View.

MVVM був розроблений з метою використання специфічних функцій у WPF для кращого полегшення відділення розробки шару View від решти шаблону, видаляючи практично весь «код-позаду» від шару View. Замість того, щоб вимагати від інтерактивних дизайнерів писати код перегляду, вони можуть використовувати рідну мову розмітки WPF XAML та створювати прив’язки до ViewModel, який записують та підтримують розробники додатків. Такий розподіл ролей дозволяє інтерактивним дизайнерам зосередитись на потребах UX, а не на програмуванні або бізнес-логіці, що дозволяє розробляти шари програми в декількох робочих потоках.

Для користувальницьких інтерфейсів, де така багата взаємодія не потрібна, MVVM може бути надмірним; MVP може бути більш природним вибором. Для веб-додатків MVC найкраще підходить. Для дуже малих додатків, які ніколи не зростатимуть більше (наприклад, невеликі утиліти Winforms), код-відстань є достатньою.

Іноді MVVM може бути пасткою. З мого досвіду він надає перевагу CRUD-подібним програмам (форми над даними) порівняно з більш орієнтованими на завдання інтерфейсами. Я не кажу, що це передбачає погану архітектуру для зворотного / інших шарів у додатку, але я бачив багато програм MVVM, що надходять із архітектурою "DDD light". Я не знаю, чому саме, можливо, тому що прив'язка настільки проста і дуже просто налаштувати додаток з ORM та MVVM / Binding за допомогою об'єктів домену POCO / Anemic.

MVVM - це смугова допомога для погано розроблених шарів зв’язування даних. Зокрема, він отримав велику користь у світі WPF / silverlight / WP7 через обмеження у прив'язці даних у WPF / XAML.

Відтепер я припускаю, що ми говоримо про WPF / XAML, оскільки це зробить все більш зрозумілим. Розглянемо деякі недоліки, які MVVM має вирішити в WPF / XAML.

Форма даних та форма інтерфейсу користувача

'VM' у MVVM створює набір об'єктів, визначених у C #, які відображають набір об’єктів презентації, визначених у XAML. Ці об'єкти C # зазвичай підключаються до XAML через властивості DataContext на об'єктах презентації.

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

Об'єктний графік viewmodel успішно відокремлює модельний графік об'єкта від графічного об'єкта ui, але за рахунок додаткового шару viewmodel, який необхідно будувати та підтримувати.

Якщо я хочу перенести деякі дані з екрана А на екран В, мені потрібно зіпсуватись із переглядами моделей. У розумі ділового хлопця, це зміна інтерфейсу користувача. Це має відбуватися виключно у світі XAML. На жаль, це рідко може. Гірше, залежно від того, як структуровані моделі перегляду та наскільки активно змінюються дані, для досягнення цієї зміни може знадобитися небагато перенаправлення даних.

Обізнання неекспресивних прив’язок даних

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

Якщо вам потрібно прив’язати властивість у C # до чогось більш складного, ніж це, вам, по суті, не пощастить. Я ніколи не бачив додаток WPF без прив'язуючого перетворювача, який перетворив true / false у Visible / Collapsed. У багатьох додатках WPF також є щось, що називається NegatingVisibilityConverter або подібне, що перевершує полярність. Це має бути вимкненням дзвінків тривоги.

MVVM дає вам вказівки щодо структурування коду C #, який можна використовувати для згладження цього обмеження. Ви можете розкрити властивість у своїй моделі перегляду під назвою SomeButtonVisibility і просто прив'язати її до видимості цієї кнопки. Ваш XAML приємний і симпатичний зараз ... але ви перетворилися на службовця - тепер вам доведеться виставити + оновлення прив’язок у двох місцях (інтерфейс користувача та код у C #), коли ваш інтерфейс розвивається. Якщо вам потрібна така ж кнопка, щоб знаходитись на іншому екрані, вам доведеться відкрити аналогічну властивість у моделі перегляду, до якого може отримати доступ цей екран. Гірше, я не можу просто подивитися на XAML і побачити, коли кнопка вже буде видно. Як тільки прив'язки стають трохи нетривіальними, мені доводиться виконувати детективні роботи в коді C #.

Доступ до даних охоплюється агресивно

Оскільки дані зазвичай надходять у користувальницький інтерфейс через властивості DataContext, важко представляти глобальні дані або дані сеансу у вашому додатку.

Ідея "поточного користувача" - прекрасний приклад - це часто справді глобальна річ в екземплярі вашого додатка. У WPF / XAML дуже важко послідовно забезпечити глобальний доступ до поточного користувача.

Що я хотів би зробити, це використовувати слово "CurrentUser" у прив'язці даних, щоб вільно посилатися на користувача, який зараз увійшов. Натомість я повинен переконатися, що кожен DataContext дає мені спосіб дістатись до об'єкта поточного користувача. MVVM може пристосувати це, але в моделях перегляду буде безлад, оскільки всі вони повинні забезпечити доступ до цих глобальних даних.

Приклад, коли MVVM перепадає

Скажімо, у нас є список користувачів. Поруч із кожним користувачем ми хочемо відобразити кнопку "видалити користувача", але лише у тому випадку, якщо користувач, який зараз увійшов у систему, є адміністратором. Також користувачі не можуть видаляти себе.

Об'єкти вашої моделі не повинні знати про поточно зареєстрованого користувача - вони просто представлятимуть записи користувачів у вашій базі даних, але якимось чином зареєстровані в даний час користувачі повинні піддаватися прив'язці даних у рядах списку. MVVM продиктує, що ми повинні створити об’єкт viewmodel для кожного списку рядків, який складається з поточного входу користувача з користувачем, представленим цим рядком списку, а потім відкрити властивість під назвою "DeleteButtonVisibility" або "CanDelete" на цьому об'єкті viewmodel (залежно від ваших почуттів) про зв'язуючі перетворювачі).

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

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

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

Як все могло бути

У випадку, описаному вище, я хочу сказати:

<Button Visibility="{CurrentUser.IsAdmin && CurrentUser.Id != Id}" ... />

CurrentUser буде виставлений на весь світ для всіх XAML в моєму додатку. Id буде посилатися на властивість у DataContext для мого рядка списку. Видимість автоматично перетвориться з булева. Будь-які оновлення Id, CurrentUser.IsAdmin, CurrentUser або CurrentUser.Id спричинить оновлення видимості цієї кнопки. Простенька.

Натомість WPF / XAML змушує своїх користувачів створювати повний безлад. Наскільки я можу сказати, деякі креативні блогери ляснули ім’я в цьому безладі, і це ім'я було MVVM. Не обманюйте - це не той самий клас, як шаблони дизайну GoF. Це некрасивий хакер для вирішення проблеми з потворною системою прив'язки даних.

(Цей підхід іноді називають "функціональним реактивним програмуванням" у випадку, якщо ви шукаєте для подальшого читання).

У висновку

Якщо вам потрібно працювати в WPF / XAML, я все одно не рекомендую MVVM.

Ви хочете, щоб ваш код був структурований так, як у прикладі "як все могло бути", це було б - модель піддається прямому перегляду зі складними виразами зв'язування даних + гнучкими коерционами значення. Це набагато краще - легше читати, читати і підтримувати.

MVVM повідомляє вам структурувати свій код більш докладно, менш рентабельним способом.

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

Ще краще - замініть XAML чимось більш виразним. XAML - це дуже простий формат XML для інстанціювання об'єктів C # - не важко буде придумати більш виразний варіант.

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

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

1. Для додатків або ігор, для яких потрібно багато коду інтерфейсу / взаємодії, щоб додати багато користувальницької поведінки, зберігаючи перф. - часто краще використовувати трохи брудний MVVM - використовувати його, коли це корисно або в більш орієнтованих на даних даних, на відміну від взаємодія центричних областей коду. Скажіть, ви хочете створити елемент управління і перемістити його між різними елементами управління або іншим чином кешувати його ...

2. Він має досить круту криву навчання, тому, якщо у вас немає часу, плануйте багато розробити в WPF / SL, не майте дизайнерів, кваліфікованих Blend, відчуйте необхідність написати тестовий код для вашого інтерфейсу або інакше розраховуйте зробити багато років обслуговування для вашого проект - він може не окупитися.

3. Не так багато дизайнерів знають Blend, не всі проекти варті того, щоб зосередитись на автоматизованому тестуванні на презентаційному шарі, оскільки його потрібно протестувати вручну, і саме так ви знайдете найважливіші помилки, а не тестуючи свої віртуальні машини.

4. Це справді інвестиція. Ви повинні спочатку зрозуміти основи WPF / SL та XAML, а потім розібратися, як правильно виконати прив'язки, підключити до vms в певному порядку, отримати командне право, вибрати рамку в більшості випадків, яка могла б бути проблематичним через ліцензування, створити бібліотеку sippets, щоб ефективно кодувати, лише щоб виявити, що платформа не завжди добре працює з прив’язками та потребує створення бібліотеки поведінки, яка отримує вам те, що вам потрібно.

Однак загалом - якщо ти подолаєш усі перешкоди і станеш досить ефективним у шаблоні - це все окупиться в ясності, ремонтопридатності та ... Похвалити права? :)

Я був програмістом WPF / Silverlight протягом багатьох років, будуючи величезні програми, такі як торгові системи, на MVVM.

Для мене, як минули роки, я дізнався, що суворий МВВМ їсть час і коштує грошей. Під суворими, я маю на увазі такі правила, як "немає коду позаду".

Неможливо ні в чому, окрім найпростішої програми / бази даних, не мати коду.

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

Я написав усі види швидкого використання інтерфейсу користувача з використанням математики, інерції, жестів і т. Д. Та її важкої роботи.

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

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

Мета MVVM - відокремити логіку програми та бізнесу від логіки інтерфейсу користувача. Система зв'язування та MVVM - це приємний спосіб зробити це.

Інші цілі, наприклад, дизайнер XAML на одному столі, програміст C # на другому, один, який працює в Blend, а інший в VS, є помилкою.

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

Для мене я використовую MVVM, щоб зберігати роздільну логіку мого додатка (я зазвичай використовую контрольований контролер і набір моделей подання даних без входу в систему), але який би код і хитрощі не потрібні, щоб мій інтерфейс виглядав і діяв сексуально, я не потіти його.

Інакше ви закінчите керувати своїми проектами, крутими анімаціями і т. Д. Лише тому, що думка про те, як MVVM-арізувати все це стає занадто приголомшливою.

MVVM, як і більшість речей у житті, має миле місце десь між двома крайнощами.

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

Якщо ваша програма вимагає прив'язування до надмірної кількості даних у режимі реального часу, тоді MVVM може насправді перешкоджати тому, що це вводить абстракції, які сповільнюють процес, і, якщо ми говоримо про WPF / Silverlight / WP7 зараз, прив'язка на даний момент двигун не настільки ефективний; хоча вдосконалення вже на шляху.

MVVM, як нині є, також не є єдиною частиною рівняння, яке потрібно розглянути. Чистий MVVM повинен підтримуватися інфраструктурою, такою як модель «Посередник», щоб ви могли спілкуватися через відключені ViewModels.

Незважаючи на думку blucz вище, MVVM знаходиться у лінійці моделей GoF. Якщо ви подивитеся на шаблони, MVVM є еквівалентом моделі пасивного презентатора View View Model, яка з’явилася приблизно в той же час, що і MVVM. Ви часто тут будете скаржитися на складність MVVM виключно через те, що вони не розуміють, як створити його за допомогою.

Інша область, у якій я виявив проблеми з MVVM, - це те, коли вам потрібно включити сторонні технології, які не розроблені для її підтримки (наприклад, UII-рамка для MS Dynamics). Часом вам доводиться запитувати себе, чи варто боліти "хакерство" навколо інших технологій просто для роботи з MVVM.

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

Використовувати MVVM не має сенсу, коли:

• Ви не працюєте з WPF або Silverlight
• Ви тестуєте концепцію

Це воно. Я не можу подумати, чому ви НЕ використовуєте MVVM під час роботи з WPF / Silverlight, якщо ви не тестуєте чи не налагоджуєте щось в окремому проекті. Я вважаю модель дизайну ідеальною для розробки WPF / Silverlight завдяки тому, як працюють прив'язки XAML.

Вся суть MVVM полягає в тому, що вся ваша програма працює у ваших ViewModels, а ваші перегляди - просто гарний шар, який користувачі можуть використовувати для взаємодії з вашими ViewModels. Ви хочете натиснути кнопку, ви фактично використовуєте метод ViewModel. Ви хочете змінити сторінку, ви фактично змінюєте властивість CurrentPage у ViewModel.

Я використовую MVVM для всіх розробок WPF / Silverlight, навіть для невеликих простих односторінкових проектів, хоча те, як я використовую MVVM, залежить від розміру проекту та того, що мені потрібно. Одного разу, коли я зробив невелику програму без MVVM, я пошкодував про це (пізніше я відновив використання MVVM під час додавання оновлення)

Я зробив певну роботу з клієнтом над проектом, який був позаду коду, намагаючись перетворити на MVVM, кинутого, і це було великим безладом. Це не означає, що всі проекти, що стоять за кодом, - це безлад. Погляди помиляться або збиваються Blend, що спричинило проблеми для дизайнерів.

Я спіймався з RoR і в значній мірі пропустив робити все, що завгодно, з ASP.NET Webforms, але коли ASP.NET MVC вийшов, я намагався навчитися якнайбільше, часто використовуючи ASP.NET MVC In Action книги та codecampserver в якості посилання . Хоча це інша картина, я використовую багато речей, які я дізнався з книг In Action в розробці SL / MVVM.

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

Я почав із чудового MVVM-Light, який допоміг мені зрозуміти, що продається. Пізніше я почав працювати з Caliburn Micro, а потім увімкнули світло. Для мене Caliburn Micro - це як ASP.NET MVC через веб-форми ASP.NET. Отже, навіть для невеликих прикладних програм я створюю проект NuGet CM, і я вимикаюсь і працюю. Я дотримуюся першого підходу ViewModel і зберігаю свої погляди тупими та зручними для роботи в Blend. Мої відеомагнітофони перевіряються, якщо ви до цього вступаєте, а з CM це досить просто прокладати складні макети екрану.

Вам може сподобатися перевірити цю альтернативу. Цей параметр уникає способу прив'язки даних, шаблонів даних та MVVM у форматі WPF. Цей параметр більше схожий на старий, простий, надійний підхід дизайнера Wincs.

Композити WPF

http://wpfcomposites.codeplex.com/

Тут стислий C #-відставання коду для WPF виробляється шляхом накладання простої матриці на поверх інтерфейсу через композити на основі сітки. Якщо сучасний інтерфейс XAML містить лише кілька текстових міток і список фотографій, чому це не можна визначити простим рядком коду: grid.AddText (керівництво, x координата, y координата)? Зауважте, це не на полотні, але все ж знаходиться в контейнерах WPF: сітка, докпанель тощо. WPF надзвичайно потужний. Цей підхід просто використовує це.

Зазвичай розробники не заперечують проти матриць та індексів. Почніть з грубозернистого рівня контейнера, визначеного GUID об'єктами передачі даних (DTO) або POCO, а потім зробіть комплімент цим заповненим контейнерам тонкозернистою матрицею потенційних рядків і стовпців всередині?

Вищенаведений проект кодеплексу запроваджує цей підхід, починаючи з керування ListBox, але розширюється, щоб охопити всі композитні елементи керування WPF. Наприклад, кожен listboxitem - це композит, доданий із GUID (складений зв'язок один до одного до класу), тоді всередині цього елемента є сітка, на якій дочірні елементи інтерфейсу (діти прив’язують один до одного властивості у класі) можуть бути додані за бажанням за допомогою коду. Діти можуть бути текстовими блоками чи зображеннями.

Ідея полягає у використанні індексів та чітко визначеної структури елементів інтерфейсу користувача (це змушує тему PresentationFramework.Aero з тематичним ListBox починати з бази) замість шаблонів даних. Цей новий підхід цілеспрямовано обмежує те, що можна зробити, але, тим самим, дає стислий, надійний код C #, що є інтуїтивно зрозумілим. Немає необхідності шукати рішення контрольних шаблонів для стилізації прокрутки або захаращувати рішення з кількома шаблонами даних для простих завдань.

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

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

Отже, у нас є класичне запитання щодо додавання шару абстракції. ВМ збирається додати вазі, інерції та структурі проекту. Це полегшить будівництво, але складніше змінити і довше будувати. Жоден із цих речей не можна легко оцінити.

Для дешевої відповіді MVVM не підходить для програм командного рядка чи веб-служб :)