Jak wybrać NIE używać frameworka (Caliburn.Micro itp.) W danej aplikacji MVVM?

Kiedyś rozpocząłem projekt MVVM / WPF, który ostatecznie został zbudowany i wdrożony, i do tego czasu studiowałem wiele Caliburn.Micro MVVM Framework. Faktem jest, że ostatecznie nie użyłem do tego Caliburn.Micro i sam wdrożyłem niektóre koncepcje MVVM (konkretnie tylko klasy ViewModelBasei RoutedCommand).

Teraz zostałem przydzielony do nieco większego projektu według tych samych zasad: „Aplikacja kliencka dla pojedynczego użytkownika, bogatego klienta offline”, że tak powiem, i zdecydowałem się użyć Caliburn.Micro. I tu zaczyna się mój „problem”.

Przeczytałem w tym słynnym poście na blogu , którego tytuł mówi: „Jeśli używasz MVVM, potrzebujesz ram”, który:

„Próba zrobienia czegoś takiego jak MVVM bez frameworka to ogromna praca. Mnóstwo zduplikowanego kodu, wynalezienie koła i przeszkolenie ludzi do myślenia w inny sposób .

Przynajmniej dzięki frameworkowi unikniesz duplikatu kodu i miejmy nadzieję, że nie musisz wymyślać koła na nowo - pozwalając ci skupić się na przekwalifikowaniu ludzi. Części do przekwalifikowania jest generalnie nieuniknione, ale platforma zapewnia kod i strukturę hydrauliczną, co ułatwia proces. „

Zgodziłbym się przy pierwszym czytaniu, ale moje rzeczywiste doświadczenie z Caliburn.Micro (CM) w moim rzeczywistego aplikacja jest od cluelessness i dezorientacja. Oznacza to, że ramy wcale nie ułatwiły tego procesu, wręcz przeciwnie. Czytanie ciągle powtarzających się przykładów dostarczonych przez Roba Eisenberga w raczej (zbyt) nieformalnej dokumentacji i próba wnioskowania o wzorcach użytkowania na podstawie skomplikowanych dostarczonych próbek oraz ich całkowicie pośrednich relacji między klasami i interfejsami, w których wydaje się, że rzeczy mają działać w oparciu o skutki uboczne wydają się po ludzku niemożliwe, chyba że jesteś doświadczonym geniuszem (przepraszam za rant, ale chyba wiesz, co mam na myśli).

Nie wspominając już o tym, że każdy trywialny scenariusz wydaje się obejmować kontenery IoC, z którym nigdy nie pracowałem i który wydaje się rozwiązać problem, którego mógłbym nawet nie mieć . Nie mam ochoty poświęcać więcej godzin na naukę tych rzeczy, zamiast myśleć o moich problemach i domenach aplikacji. Chciałem tylko banana, ale CM dał mi goryla (IoC) z koszem bananów.

Teraz, gdy zastanawiam się nad powrotem do mojego samodziałającego frameworka MVVM - złożonego tylko z kilku klas specyficznych dla MVVM, które tak naprawdę chcę wdrożyć - chciałbym przynajmniej dać CM szansę, na wypadek, gdyby coś tu straciłem, lub po prostu robienie rzeczy „w niewłaściwy sposób” z czystego braku doświadczenia i ignorancji. Tak więc pytanie brzmi:

Panuje powszechna zgoda co do tego, że „frameworki sprawiają, że rzeczy stają się łatwiejsze i bardziej naturalne”, ale jeśli doświadczam czegoś wręcz przeciwnego, czy to oznacza, że ​​nie powinienem używać frameworka lub że staram się go nauczyć w niewłaściwy sposób? Czy istnieje wskazówka, że ​​w ogóle nie powinienem używać frameworka? Czy jest jakiś „właściwy” sposób, aby dowiedzieć się, jak używać CM do prostego programowania MVVM?

Próbowałem CaliburnMicro i MVVMLight, a podczas korzystania z Caliburn naprawdę czuję to, co czujesz, na pewno naprawdę magicznie jest w stanie powiązać kontrolę z właściwością za pomocą Name = "PropertyName" zamiast starego Text = "{Bind PropertyName}", ale w koniec Caliburn idzie o krok za burtą, aby zrobić tę magiczną rzecz, gdy coś pójdzie nie tak, naprawdę trudno ją debugować, a co gorsza, ma wiele sposobów na zrobienie jednej rzeczy.

Ale kiedy używasz MVVMLight, jest cienki, kiedy go używasz, prawdopodobnie zdajesz sobie sprawę, że jest prawie w 100% podobny do twojego MVVM Framework, z pewnymi funkcjami.

Wiem, że to nie odpowiada na pytanie „Jak NIE używać frameworka”, ale szczerze mówiąc, nie mogę polecić ci pójścia tą drogą, ponieważ to po prostu źle, myślę też, że po prostu się zgubiłeś, ponieważ używasz w pełni funkcjonalnego frameworka zamiast prostego jeden pierwszy.

Ważne jest, aby zrozumieć, co to jest MVVM. Nie jest to wspólny element funkcjonalności, którego nie trzeba ponownie wdrażać (parsowanie pliku JPEG lub połączenie z danym serwerem bazy danych SQL), to wzorzec - wzorzec, w jaki sposób można wdrożyć bogaty interfejs GUI. Tak więc, jeśli implementacja wzorca jest prosta i jednoznaczna, nie sądzę, że powinieneś odczuwać wstyd przy jego stosowaniu zamiast frameworku.

Rzeczywiście uważam, że cała idea wzorców jako ram została za daleko posunięta. Aby cokolwiek było wzorem, musi to być ogólny kształt klasy rozwiązań. Ponieważ tak jest, należy oczekiwać, że wzorce będą musiały być dostosowane do systemów, które ich używają, i nie można tego zrobić, jeśli spróbujesz zastosować wzór uniwersalny. Znacznie bardziej konstruktywne byłoby pozostawienie implementacji wzorców projektantowi aplikacji i zapewnienie bibliotek, które zawierają funkcjonalność, a nie architekturę.

Moje pierwsze doświadczenie z WPF polegało na korzystaniu z Caliburn.Micro, więc prawdopodobnie różni się to od większości programistów. Zauważyłem, że zarówno WPF, jak i Caliburn.Micro to dość stroma krzywa uczenia się, pochodząca z WinForms, jednak po pewnym doświadczeniu z obiema z nich odkryłem, że z przyjemnością używam ich jako pary. Obecnie pracuję w innej organizacji, w której nie jest używany Caliburn.Micro, okazuje się, że jest DUŻO zduplikowanego kodu hydraulicznego, co powoduje, że podstawa kodu jest bardzo rozdęta i niepotrzebnie złożona.

Zdecydowanie zgadzam się, że istnieją pewne problemy z Caliburn.Micro, które mogą komplikować debugowanie, jednak po doświadczeniu są znacznie mniej prawdopodobne, że znów będą uciążliwe. Zwiększona szybkość programowania, bardziej przejrzysty i uproszczony kod oraz ogólna struktura zachęcająca do lepszego MVVM są dla mnie więcej niż warte.

Caliburn.Micro również nie unieważnia zapasowego WPF - po prostu buduje się na nim, co oznacza, że ​​nadal możesz korzystać z funkcji WPF, jeśli chcesz, i używać Caliburn do kilku bitów, jeśli chcesz. Jest to podobne do tego, jak TypeScript i JavaScript współistnieją w moim umyśle.

Zdecydowanie użyłbym Caliburn.Micro w każdym nowym projekcie WPF, nad którym pracuję w przyszłości, jeśli będzie taka możliwość.

Dla każdego, kto przybywa tutaj z frustracji z Caliburn.Micro, spójrz na ten framework: Stylet

Jest zainspirowany Caliburn.Micro, ale usuwa wiele magii, która powoduje, że jesteś zdezorientowany co się dzieje. Dodatkowo dokumentacja jest napisana w dużo prostszym języku bez zakładania, że ​​chcesz przebrnąć przez techniczny żargon. Znacznie lepiej dla początkujących.

Ponadto Stylet stosuje podejście ViewModel-First. Caliburn.Micro i wiele innych frameworków stosuje podejście View-First, co wiąże się z pewnymi niezręcznymi problemami. Jeśli jesteś już bardzo dobry w zasadach SOLID i kodzie wzorzystym, prawdopodobnie podejście ViewModel-First jest bardziej naturalne, ponieważ bierze pod uwagę perspektywę, że twoja logika powinna sterować systemem - a nie widok.