Як вибрати НЕ використовувати фреймворк (Caliburn.Micro тощо) у даній програмі MVVM?

Я колись розпочав проект MVVM / WPF, який згодом був розроблений та розгорнутий, і для цього я вивчив багато рамок Caliburn.Micro MVVM. Справа в тому, що я в кінцевому підсумку не використовував Caliburn.Micro для цього, і в кінцевому підсумку я реалізував деякі концепції MVVM (конкретно, просто ViewModelBaseі RoutedCommandкласи).

Тепер мене призначили дещо масштабнішим проектом за такими ж напрямками: "Однокористувацький клієнт, який працює в режимі офлайн на робочому столі", так би мовити, і я вирішив використовувати Caliburn.Micro. І ось тут починається моя «проблема».

Я читав у цій відомій публікації в блозі , назва якої говорить, що "Якщо ви використовуєте MVVM, тоді вам потрібна рамка", що:

"Спроба зробити щось на кшталт MVVM без фреймворку - це величезна робота. Тони дублювання коду, винахід колеса і перекваліфікація людей думати інакше .

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

Я погодився б у першому читанні, але мій фактичний досвід роботи з Caliburn.Micro (CM) у моєму реальному застосуванні полягає у незрозумілості та дезорієнтації. Тобто, рамки зовсім не полегшили процес, навпаки. Читання постійно повторюваних прикладів, наданих Роб Айзенбергом у досить (занадто) неформальній документації, та намагання вивести схеми використання з суперечливо наданих зразків та їх абсолютно непрямих зв’язків між класами та інтерфейсами, де речі, здається, покликані працювати на основі побічні ефекти, здаються по-людськи неможливими, якщо ви не досвідчений геній (вибачте за рент, але я думаю, ви знаєте, що я маю на увазі).

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

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

Існує поширений консенсус, що "рамки полегшують і природніші речі", але якщо я трапляюсь зовсім навпаки, чи означає це, що я не повинен використовувати рамки, або що я намагаюся навчитися цьому неправильно? Чи є поняття, що я в першу чергу навіть не повинен використовувати рамки? Або є якийсь "правильний" спосіб розібратися, як використовувати CM для простого розвитку MVVM?

Я спробував CaliburnMicro та MVVMLight і під час використання Caliburn я справді відчуваю те, що ви відчуваєте, переконайтесь, що він відчуває себе дійсно магічним, здатний прив’язати контроль до власності просто за допомогою Name = "PropertyName" замість старого Text = "{Bind PropertyName}", але в в кінці Калібурн переходить шлях за борт, щоб зробити цю магічну річ, коли щось піде не так, це дуже важко налагодити, а ще гірше - у них є багато способів зробити одне.

Але при використанні MVVMLight він тонкий, коли ви користуєтесь ним, ви, мабуть, розумієте, що він майже на 100% схожий на ваш MVVM Framework, з деякою функцією, посипаною в ньому.

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

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

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

Мій перший досвід роботи з WPF - це використання Caliburn.Micro, тому це, мабуть, зовсім відрізняється від більшості розробників. Я виявив, що WPF і Caliburn.Micro є досить крутою кривою навчання, що виходить від WinForms, проте після деякого досвіду роботи з обома я знайшов їм задоволення використовувати як пару. В даний час працюю в іншій організації, де Caliburn.Micro не використовується, я виявляю, що існує багато дублікатів сантехнічного коду, що робить базу коду досить роздутою і без зайвих труднощів.

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

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

Я б, безумовно, використовував Caliburn.Micro в будь-якому новому проекті WPF, над яким я буду працювати в майбутньому, якщо дадуть можливість.

Для всіх, хто приїздить сюди невдоволений Caliburn.Micro, погляньте на цю рамку: Stylet

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

Також Stylet використовує підхід ViewModel-First. Caliburn.Micro та безліч інших фреймворків використовують підхід View-First, який має деякі незручні проблеми. Якщо ви вже дуже добре ставитеся до принципів SOLID та візерункового коду, ви, швидше за все, знайдете підхід ViewModel-First більш природним, оскільки він вимагає точки зору, що ваша логіка повинна керувати системою - а не вигляд.