Навіщо використовувати MVVM?

Гаразд, я вивчав шаблон MVVM, і кожного разу, коли я намагався розглянути його, я відмовлявся з ряду причин:

1. Непотрібне надмірно довге кодування
2. Немає очевидних переваг для кодерів (у моєму офісі немає дизайнерів. Наразі лише я скоро стану іншим кодером)
3. Небагато ресурсів / документації з передового досвіду! (Або принаймні важко знайти)
4. Не можу придумати жодного сценарію, коли це вигідно.

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

Я, чесно кажучи, не бачу переваги використання цього для кодування одного / партнера. Навіть у складних проектах з 10 вікнами. Для мене DataSet - це досить хороший вигляд та обов’язковість, як у відповіді Брента на наступне запитання

Чи може хтось показати приклад того, як використання шаблону MVVM може заощадити час у порівнянні з XAML DataBinding.

На даний момент 100% мого прив’язки виконується в XAML. І тому я не бачу сенсу у віртуальній машині як у простому додатковому коді, за яким мені потрібно писати і залежати від нього.

EDIT:
Провівши півдня, досліджуючи MVVM, я нарешті знайшов щось, що змусило мене зрозуміти справжні переваги цієї відповіді .

Резюме

• Використання всіх моделей є ситуативним, і користь (якщо така є) завжди полягає у зменшенні складності.
• MVVM допомагає нам розподілити обов'язки між класами в програмі графічного інтерфейсу.
• ViewModel проектує дані з Моделі у формат, який відповідає поданню.
• Для тривіальних проектів MVVM непотрібний. Достатньо користуватися лише видом.
• Для простих проектів розбиття ViewModel / Model може бути непотрібним, і просто використання Model and View досить добре.
• Model і ViewModel не повинні існувати з самого початку і можуть бути введені, коли вони потрібні.

Коли використовувати шаблони, а коли уникати їх

Для досить простого застосування кожен шаблон дизайну є надмірним. Припустимо, ви пишете програму графічного інтерфейсу, яка відображає одну кнопку, яка при натисканні відображає "Hello world". У цьому випадку такі шаблони дизайну, як MVC, MVP, MVVM, додають багато складності, не додаючи жодної цінності.

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

Для пояснення знайомої та незнайомої складності візьміть наступні 2 послідовності символів:

• "D. € | Ré% dfà? C"
• "CorrectHorseBatteryStaple"

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

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

МВВМ

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

«Правильний» MVVM передбачає принаймні помірно складний додаток, який має справу з даними, отриманими звідкись. Він може отримувати дані з бази даних, файлу, веб-сервісу або з безлічі інших джерел.

Приклад

У нашому прикладі ми маємо 2 класи Viewта Model, але ні ViewModel. ModelОбертає CSV-файл , який він зчитує при запуску і зберігає , коли закривається додаток вниз, всі зміни користувача , внесений в дані. Це Viewклас Window, який відображає дані з Modelтаблиці та дозволяє користувачеві редагувати дані. Вміст csv може виглядати приблизно так:

ID, Name, Price
1, Stick, 5$
2, Big Box, 10$
3, Wheel, 20$
4, Bottle, 3$

Нові вимоги: Показати ціну в євро

Тепер нас просять внести зміни в нашу заявку. Дані складаються з двовимірної сітки, яка вже має стовпець "ціна", що містить ціну в доларах США. Нам потрібно додати новий стовпець, який відображає ціни в євро на додаток до цін у доларах США на основі заздалегідь визначеного обмінного курсу. Формат csv-файлу не повинен змінюватися, оскільки інші програми працюють з цим же файлом, і ці інші програми не під нашим контролем.

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

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

Представляємо ViewModel

У ViewModelдодатку немає, оскільки до цього Modelчасу дані подають дані саме так, як це потрібно CSv, а також так, як Viewце потрібно. Наявність ViewModelміж ними додало б складності без мети. Але тепер, коли дані Modelбільше не подають дані так, як вони Viewпотрібні, ми пишемо a ViewModel. У ViewModelпроектах даних Modelтаким чином , що Viewможе бути простою. Раніше Viewклас передплачував Modelклас. Тепер новий ViewModelклас підписується на Modelклас і виставляє Modelдані з View- із додатковою колонкою, що відображає ціну в євро. Більше Viewне знаєModel, тепер він знає лише те ViewModel, що з точки зору Viewвиглядає так само, як Modelі раніше - за винятком того, що відкриті дані містять новий стовпець лише для читання.

Нові вимоги: інший спосіб форматування даних

Наступним запитом замовника є те, що ми не повинні відображати дані у вигляді рядків у таблиці, а натомість відображатимемо інформацію про кожен елемент (він же рядок) як картку / коробку та відображатимемо 20 вікон на екрані в сітці 4x5, показуючи 20 коробки за раз. Оскільки ми дотримувались логіки Viewпростого, ми просто замінюємо Viewцілком новий клас, який робить, як замовник бажає. Звичайно, є ще один клієнт, який віддав перевагу старому View, тому зараз нам потрібно підтримати обох. Тому що вся загальна бізнес-логіка вже трапляється в тому, ViewModelщо не є великою проблемою. Тож ми можемо вирішити це, перейменувавши клас View у TableViewта написавши новийCardViewклас, який відображає дані у форматі картки. Нам також доведеться написати певний код клею, який може бути однолінійним у функції запуску.

Нові вимоги: динамічний курс обміну

Наступним запитом клієнта є те, що ми витягуємо обмінний курс з Інтернету, а не використовуємо заздалегідь визначений обмінний курс. Це момент, коли ми знову переглядаємо моє попереднє твердження про "шари". Ми не змінюємо наш Modelклас, щоб забезпечити обмінний курс. Натомість ми пишемо (або знаходимо) абсолютно незалежний додатковий клас, який забезпечує обмінний курс. Цей новий клас стає частиною рівня моделі, і ми ViewModelконсолідуємо інформацію csv-Моделі та Моделю обмінного курсу, яку він потім представляє View. Для цієї зміни старий клас Model і клас View навіть не потрібно торкатися. Що ж, нам потрібно перейменувати клас Model на, CsvModelі ми викликаємо новий клас ExchangeRateModel.

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

Післямова про одиничні тести

Основна мета MVVM не полягає в тому, що код у Моделі та ViewModel може бути поміщений в Unit Test. Основна мета MVVM полягає в тому, що код розбивається на класи з невеликою кількістю чітко визначених обов'язків. Однією з кількох переваг наявності коду, що складається з класів з невеликою кількістю чітко визначених обов’язків, є те, що простіше поставити код під модульний тест. Набагато більша перевага полягає в тому, що код легше розуміти, підтримувати та модифікувати.

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

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

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

Думка про використання наборів даних для вашої моделі : (Я насправді теж полюбила це.) Набори даних здаються цілком дійсним способом переміщення даних моделі у програмі. Проблема полягає в тому, як ви ідентифікуєте елементи даних. Оскільки ваші дані зберігаються в рядках і стовпцях, вам доведеться виконувати пошук за іменем або індексом стовпця, а також фільтрувати певний рядок. Ці біти логіки означають необхідність використання магічних рядків і цифр для логіки підключення у вашому додатку. Використання набраного набору даних полегшить деякі проблеми, але не повністю. Використовуючи набрані набори даних, ви віддаляєтесь від MVVM і тісніше поєднуєте інтерфейс користувача з джерелом даних.

Це допомагає розділити графічний інтерфейс і логіку програми; їх змішування може призвести до дуже важких для обслуговування програм, особливо коли ваш проект зростає з часом.

Від сюди :

Чому вам, як розробнику, навіть потрібно піклуватися про шаблон Model-View-ViewModel? Цей шаблон має ряд переваг як для WPF, так і для розробки Silverlight. Перш ніж продовжувати, запитайте себе:

• Чи потрібно вам ділитися проектом з дизайнером і мати гнучкість, щоб проектні роботи та розробки могли відбуватися майже одночасно?
• Вам потрібне ретельне модульне тестування для ваших рішень?
• Чи важливо для вас мати багаторазові компоненти як в рамках, так і між проектами у вашій організації?
• Чи хотіли б ви більшої гнучкості для зміни користувальницького інтерфейсу без необхідності рефакторингу іншої логіки в основі коду?

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

• Простіше працювати з дизайнерами (не програмістами, а просто людьми, які використовують Blend)
• Код перевіряється (модульні тести)
• Набагато простіше змінити вигляд, не возившись з рештою коду
• Поки ви розробляєте користувальницький інтерфейс, ви можете знущатись над моделлю та розробляти свій інтерфейс, не запускаючи реальну службу (просто використовуючи макетні дані з моделі). Тоді ви просто перевертаєте прапор і підключаєтесь до служби.

Зі статті Джоша Сміта про MVVM :

На додаток до функцій WPF (і Silverlight 2), які роблять MVVM природним способом структурування програми, шаблон також популярний, оскільки класи ViewModel легко пройти модульне тестування. Коли логіка взаємодії програми живе у наборі класів ViewModel, ви можете легко написати код, який її перевіряє. У певному сенсі Views та модульні тести - це лише два різні типи споживачів ViewModel. Набір тестів для програми ViewModels забезпечує безкоштовне та швидке тестування регресії, що допомагає зменшити витрати на підтримку програми з часом.

Для мене це найважливіша причина використовувати MVVM.

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

У MVVM є багато хороших речей, але, мабуть, найголовніше - це можливість тестувати свій код (модульне тестування ViewModels).

Відсутність зв'язку між видом та viewmodel дійсно також допомагає вільному зчепленню. Повторно використовувати компоненти, які ви кодуєте, стає дуже легко.

Прочитайте вступ до MVVM у цій статті

У 2005 році Джон Госсман, в даний час один із архітекторів WPF та Silverlight в Microsoft, представив у своєму блозі шаблон Model-View-ViewModel (MVVM). MVVM ідентичний презентаційній моделі Фаулера, оскільки обидва візерунки мають абстракцію подання, що містить стан і поведінку подання. Фаулер представив Презентаційну модель як засіб створення незалежної від платформи інтерфейсу абстракції подання, тоді як Госсман представив MVVM як стандартизований спосіб використати основні функції WPF для спрощення створення користувальницьких інтерфейсів. У цьому сенсі я вважаю MVVM спеціалізацією більш загального шаблону ПМ, спеціально розробленого для платформ WPF та Silverlight.

..

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

Також у статті пояснюється, чому використовувати такі графічні інтерфейси:

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

Розробники часто навмисно структурують свій код відповідно до шаблону дизайну, на відміну від того, щоб дозволити шаблонам виникати органічно. У жодному з підходів немає нічого поганого, але в цій статті я розглядаю переваги явного використання MVVM як архітектури програми WPF. Назви певних класів включають добре відомі терміни з шаблону MVVM, наприклад закінчуються "ViewModel", якщо клас є абстракцією подання. Цей підхід допомагає уникнути когнітивного хаосу, згаданого раніше. Натомість ви можете щасливо існувати в стані контрольованого хаосу, що є природним станом справ у більшості професійних проектів з розробки програмного забезпечення!

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

1. Я активно використовую RelayCommand від Фонду MVVM Джоша Сміта . Це робить прив’язку з View до ViewModel за допомогою команд набагато чистішою.

2. Я використовую AOP, щоб полегшити біль від впровадження INotifyPropertyChanged. В даний час я використовую Postsharp, хоча я вважаю, що існують інші інструменти, які можуть це зробити. Якби я цього не виявив, я, мабуть, уже кинув би, оскільки шаблонний код для його реалізації вручну насправді зловмивав.

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

   • Це те, що я вмію робити

   • Це те, що мені потрібно зробити

Коли ви починаєте структурувати свій код таким чином і використовуєте інструменти, що спрощують з'єднання залежностей (на вибір є широкий спектр IoC-платформ), я виявив, що це полегшує деякі незручності MVVM, оскільки Ви можете зменшити шаблонний код, пов’язаний з ін’єкцією Моделей у ViewModels та визначенням різних Служб Перегляду (наприклад, відображення діалогових вікон файлів) для споживання Ваших ViewModels.

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

Для вирішення питання про INotifyPropertyChanged через Postsharp я використовую Aspect на основі прикладу тут . Я трохи налаштував його для свого використання, але це дає вам суть. Завдяки цьому я просто позначаю клас [NotifyPropertyChanged], і всі загальнодоступні властивості матимуть шаблон, реалізований у своїх установниках (навіть якщо вони встановлюють автоматичні властивості). Мені здається набагато чистішим, оскільки мені більше не потрібно турбуватися про те, чи хочу я витратити час, щоб клас реалізував INotifyPropertyChanged. Я можу просто додати атрибут і закінчити з ним.

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

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

Переваги MVVM

1. Знижена складність.
2. Ізоляція проектування та розробки.
3. Ін’єкція залежності.
4. Основна перевага полягає в тому, що у вас є добре структурована програма MVVM для Windows Phone і ви хочете розробити таку ж для Windows Metro Desktop. Тільки те, що ви хочете сконцентруватись на дизайні, оскільки таку ж модель представлення можна використовувати, як вона є.

Сподіваюся, це допоможе.

MVVM - справді надмірний код.

То які переваги дає MVVM?

Це просто Поділ проблем не більше. Ви також можете записати логіку ViewModel в контролер. ViewModel просто повторюваний для перетворення (наприклад, об'єкта в рядок). Використовуючи MVVM, ви використовуєте більш об'єктно-орієнтований стиль програмування. Записуючи логіку перетворення в контролер, ви використовуєте більш функціональний стиль програмування.

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

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