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


28

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?


1
Osobiście wybieram elementy z każdego frameworka, aby użyć ich do określonych zachowań, a resztę ignoruję. Na przykład lubię używać Microsoft PRISM EventAggregatordo przesyłania wiadomości i NotificationObjectViewModelBase, a MVVM Light RelayCommanddo poleceń. Ważne jest, aby określić, jakie problemy rozwiąże dla Ciebie środowisko, i używaj tylko tych rozwiązań. Nie czuj się zmuszony do korzystania z całej biblioteki frameworka.
Rachel

@Rachel Planowałem użyć tego podejścia z Caliburn.Micro, ale nie mogłem znaleźć RelayCommandimplementacji (ponieważ „wiąże się” bezpośrednio z metodami zgodnie z konwencją, zamiast wiązania z właściwościami ICommand).
heltonbiker

Nigdy nie korzystałem z frameworka Caliburn, ponieważ nie podobało mi się, jak blisko wiązało się widoki z warstwą Model / ViewModel. W twoim przypadku nie widzę żadnego powodu, dla którego nie mógłbyś użyć RelayCommandinnej biblioteki, jeśli ta używana przez Caliburn Micro nie działa dla ciebie.
Rachel

@Rachel odnośnie „jak blisko [caliburn] wiąże widok z warstwą MVM”, co dokładnie masz na myśli? Jaki byłby „nieskalibrowany” sposób wiązania tych warstw w lepszy, bardziej MVVM? (Pytam szczerze, ponieważ obecnie nie wiem).
heltonbiker

Szczerze mówiąc, nigdy nie korzystałem z Caliburn Micro, więc czuję, że źle oceniam framework. Pamiętam, że miałem wrażenie, że widok został utworzony jako pierwszy i był odpowiedzialny za decydowanie o obiektach kodu, co mi się nie podoba, ponieważ nie lubię programowania View-First. Innym było powiązanie automagiczne, które polegało na tym, jak nazwałeś komponenty XAML, ponieważ myślałem, że zbyt mocno powiązało interfejs użytkownika z warstwą biznesową. Słyszałem jednak dobre rzeczy o frameworku i nie sugerowałbym unikania go tylko z mojej opinii. Wypróbuj sam i przekonaj się, czy ci się podoba :)
Rachel

Odpowiedzi:


16

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.


Czy uważasz, że powinienem przynajmniej spróbować użyć MVVMLight jako pewnego rodzaju „lekarstwa” z „dezorientacji Caliburn.Micro”? Na pewno rzuciłbym okiem, jeśli tak jest.
heltonbiker

@heltonbiker Zdecydowanie, spróbuj. Jest to o wiele prostsze, co najmniej powinno dać ci dobrą pozycję na frameworku MVVM.
kirie

Zgadzam się, że dzieje się o wiele za dużo magii. Zakładam, że pochodzę z ac i tła montażowego. E coś nie zadziała tylko po to, aby to stwierdzić ze względu na magię w tle. Niemożliwe jest debugowanie, a gdy masz problemy z wydajnością, często niewiele możesz z tym zrobić.
rzuca

10

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ę.


2
Ponadto brakuje bardzo MVVM oferowanej przez Microsoft (po wyjęciu z pudełka, WPF). Bardzo frustrujące nawet dla programistów, którzy myślą o sobie (i słusznie) jako doświadczonych programistach. Magiczne ciągi, niejasne wyjątki w środowisku wykonawczym, najbardziej podstawowe rzeczy, takie jak wiązanie grupy przycisków radiowych z wyliczeniem, wyglądają jak stackoverflow.com/q/397556/168719 - co mogą zrobić frameworki? Muszą albo powtórzyć ten poziom złożoności, albo spróbować nadać mu naprawdę grubą abstrakcję
Konrad Morawski

2
@KonradMorawski WPF sam w sobie nie jest MVVM; możesz zrobić kod za pomocą WPF, ale to nie jest MVVM. Więc jeśli chcesz zrobić WPF i MVVM, musisz użyć frameworka MVVM lub sam go zaimplementować.
Andy,

1
@ Oczywiście, ale można śmiało powiedzieć, że WPF jest przeznaczony dla MMVM. Mam na myśli funkcjonalność MVVM, która jest wbudowana w WPF. Wiem, że nadal możesz zrobić kod za
Konrad Morawski

@KonradMorawski Możesz używać WPF z MVVM, a oni zbudowali go z myślą o tej możliwości, ale nie ma ŻADNEJ funkcji specyficznej dla MVVM wbudowanej w WPF. Tak jak możesz używać MVP z WinForms, ale WinForms nie oferuje nic konkretnego do użycia tego wzorca, to zależy od ciebie.
Andy,

3
@ I może teraz kłócimy się o definicje. Mam na myśli to, że cały „klej”, który umożliwia MVVM, już istnieje - powiązania danych w XAML DataContextitp.
Konrad Morawski

7

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ść.


3
Dzięki za odpowiedź. Dwa lata później znacznie łatwiej „zaakceptowałem” te frameworki po zrozumieniu koncepcji pojemników do wstrzykiwań zależnych, czego nauczyłem się z doskonałej książki Marka DI Seemana „DI in .NET”.
heltonbiker

1

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.