Kiedyś zacząłem projekt MVVM / WPF, który został ostatecznie zbudowany i wdrożony, i w tym celu dużo przestudiowałem strukturę Caliburn.Micro MVVM. Fakt jest taki: skończyło się na tym, że nie użyłem do tego Caliburn.Micro i ostatecznie zaimplementowałem niektóre koncepcje MVVM (konkretnie tylko ViewModelBase i RoutedCommand klasy).
Teraz zostałem przydzielony do nieco większego projektu na tych samych zasadach: a ” Jeden użytkownik Rich Client Offline Desktop „, że tak powiem, i zdecydowałem się użyć Caliburn.Micro. I tam zaczyna się mój ” problem „.
Przeczytałem w ten słynny post na blogu , którego tytuł mówi, że ” Jeśli” używasz MVVM, to potrzebujemy platformy „, która:
” Próba wykonania czegoś takiego jak MVVM bez frameworka to ogromna praca. Mnóstwo zduplikowanego kodu, ponowne wymyślenie koła i przekwalifikowanie ludzi do innego myślenia .
Przynajmniej z framework, dzięki któremu unikniesz powielania kodu i miejmy nadzieję, że nie będziesz musiał odkrywać koła na nowo – co pozwoli ci skupić się na przekwalifikowaniu ludzi. Część dotycząca ponownego szkolenia jest generalnie nieunikniona, ale framework zapewnia kod i strukturę hydrauliczną, ułatwiając proces. ”
Zgadzam się po pierwszym czytaniu, ale moje rzeczywiste doświadczenia z Caliburn.Micro (CM) w mojej aktualnej aplikacji jest brak pojęcia i dezorientacja. Oznacza to, że framework wcale nie ułatwiał tego procesu, wręcz przeciwnie. Czytając ciągle powtarzające się przykłady podane przez Roba Eisenberga w raczej (zbyt) nieformalnej dokumentacji i próbując wywnioskować wzorce użycia na podstawie zawiłych dostarczonych próbek, a ich całkowicie pośrednie relacje między klasami i interfejsami, w których rzeczy wydają się być zaprojektowane tak, aby działać w oparciu o skutki uboczne, wydają się po ludzku niemożliwe, chyba że jesteś doświadczonym geniuszem (przepraszam za tyradę, ale myślę, że wiesz co mam na myśli).
Nie wspominając już o tym, że jakikolwiek powyżej trywialny scenariusz wydaje się obejmować kontenery IoC, z czym nigdy nie pracowałem i które wydają się rozwiąż problem, którego mógłbym nawet nie mieć . Nie mam ochoty spędzać więcej godzin na nauce tych rzeczy, zamiast myśleć o moim problemie i domenach aplikacji. Chciałem tylko banana, ale CM dał mi goryla (IoC) trzymającego koszyk bananów.
Teraz, kiedy rozważam powrót do mojej własnej struktury MVVM – składającej się tylko z kilku MVVM- konkretne klasy, które faktycznie chcę zaimplementować – chciałbym przynajmniej dać CM szansę na wypadek, gdyby coś tu zgubiłem, lub po prostu robię rzeczy ” w niewłaściwy sposób ” z powodu braku doświadczenia i ignorancji. Powstaje więc pytanie:
Istnieje powszechna zgoda co do tego, że ” frameworki sprawiają, że wszystko jest łatwiejsze i bardziej naturalne „, ale jeśli doświadczam czegoś zupełnie odwrotnego, czy to oznacza, że nie powinienem używać frameworka, czy też próbuję się go nauczyć w niewłaściwy sposób? wskazówka, że w ogóle nie powinienem używać frameworka w pierwszej kolejności? A może jest jakiś ” właściwy ” sposób, aby dowiedzieć się, jak używać CM do prostego programowania MVVM?
Komentarze
Odpowiedz
Próbowałem CaliburnMicro i MVVMLight a kiedy używam Caliburn, naprawdę czuję to, co czujesz, jestem pewien, że to naprawdę magiczne uczucie, że mogę powiązać kontrolkę z właściwością po prostu za pomocą Name = ” PropertyName ” zamiast starego Text = ” {Bind PropertyName} „, ale ostatecznie Caliburn robi to za burtę, aby zrobić tę magiczną rzecz . Kiedy coś idzie nie tak, debugowanie jest naprawdę trudne, a co gorsza, istnieje wiele sposobów na zrobienie jednej rzeczy.
W przeciwieństwie do tego MVVMLight jest naprawdę cienki. Kiedy go używasz, prawdopodobnie zdajesz sobie sprawę, że jest prawie w 100% podobny do twojego MVVM Framework, z pewnymi funkcjami w nim zawartymi.
Wiem, że to nie odpowiada na twoje pytanie ” Jak NIE używać frameworka „, ale szczerze mówiąc, nie mogę polecić ci pójścia tą drogą. Myślę, że zgubiłeś się, ponieważ użyłeś w pełni funkcjonalnego frameworka zamiast najpierw użyć prostego.
Komentarze
- Czy myślisz, że że powinienem przynajmniej spróbować użyć MVVMLight jako pewnego rodzaju ” leczyć ” z ” Caliburn.Micro dezorientacja „? Na pewno bym się przyjrzał, jeśli tak jest.
- @heltonbiker Zdecydowanie spróbuj. Jest to o wiele prostsze, powinno przynajmniej dać ci dobry punkt zaczepienia w MVVM Framework.
- Zgadzam się, że dzieje się zbyt wiele magii. Zakładam, że wywodzę się z tła C i Assembly. Coś wygrało ' nie działa tylko po to, by znaleźć to, co działa z powodu magii w tle. Niemożliwe do debugowania, a jeśli masz problemy z wydajnością, często niewiele można z tym zrobić.
Odpowiedź
Ważne jest, aby zdać sobie sprawę, czym jest MVVM. To nie jest jakaś wspólna funkcjonalność, której nie trzeba reimplementować (parsowanie pliku JPEG lub łączenie się z danym serwerem bazy danych SQL), jest to wzorzec – wzorzec na to, jak można wybrać zaimplementować bogate GUI. Tak więc, jeśli implementacja wzorca jest prosta i nieskomplikowana, nie sądzę, abyś czuł się wstydem, używając go, a nie frameworka.
Rzeczywiście, uważam, że cała idea wzorców jako ram posunął się zbyt daleko. Aby cokolwiek było wzorem, musi to być ogólny kształt klasy rozwiązań. Ponieważ tak jest, należy się spodziewać, że wzory będą musiały być dostosowane do systemów, które ich używają, a nie można tego zrobić, próbując użyć jednego rozmiaru dla wszystkich. Znacznie bardziej konstruktywne byłoby pozostawienie implementacji wzorców projektantowi aplikacji i udostępnienie bibliotek, które hermetyzują funkcjonalność zamiast architektury.
Komentarze
- Dodano do że MVVM oferowany przez Microsoft (po wyjęciu z pudełka, WPF) bardzo brakuje. Bardzo frustrujące nawet dla programistów, którzy myślą o sobie (i słusznie) jako o doświadczonych programistach. Magiczne ciągi, niejasne wyjątki w czasie wykonywania, większość podstawowych rzeczy, takich jak wiązanie grupy przycisków radiowych z wyliczeniem, wygląda tak: stackoverflow.com/q/397556/168719 – co czy frameworki potrafią? Muszą albo powtórzyć ten poziom złożoności, albo spróbować dostarczyć naprawdę grubą abstrakcję.
- @KonradMorawski WPF sam w sobie nie jest MVVM; możesz wykonać kod za pomocą WPF, ale to ' nie jest MVVM. Więc jeśli chcesz korzystać z WPF i MVVM, ' będziesz musiał użyć frameworku MVVM lub zaimplementować go samodzielnie.
- @Andy oczywiście, ale ' można śmiało powiedzieć, że WPF jest przeznaczony dla MMVM.' m. Odnoszę się do funkcji MVVM, która jest wbudowana w WPF. Wiem, że nadal możesz tworzyć kod za
- @KonradMorawski Możesz używać WPF z MVVM, a oni zbudowali go z myślą o tej możliwości, wierząc, 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 specjalnie do użycia tego wzorca, to zależy od Ciebie.
- @Andy może my ' ponownie się kłócimy definicje teraz. Chodzi mi o to, że cały ” klej „, który umożliwia MVVM, już istnieje – powiązania danych w XAML,
DataContextitd.
Odpowiedź
Moje pierwsze doświadczenie z WPF dotyczyło Caliburn. Micro, więc prawdopodobnie różni się od większości programistów. Zauważyłem, że zarówno WPF, jak i Caliburn.Micro są dość stromą krzywą uczenia się, pochodzącą z WinForms, jednak po pewnym doświadczeniu z oboma stwierdziłem, że z przyjemnością używam ich jako pary. Obecnie pracuję w innej organizacji, w której nie używa się Caliburn.Micro.Odkryłem, że jest DUŻO zduplikowanych kodów hydraulicznych, co sprawia, że baza kodu jest dość rozdęta i niepotrzebnie skomplikowana.
Zdecydowanie zgadzam się, że jest kilka problemów z Caliburn.Micro, który może komplikować debugowanie, jednak raz doświadczony, jest znacznie mniej prawdopodobne, że ponownie będzie bolesny. Zwiększona prędkość programowania, czystszy i szczuplejszy 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 standardowego WPF – po prostu buduje na nim, co oznacza, że nadal możesz używać funkcji WPF, jeśli chcesz i używać Caliburn dla kilku bitów i kawałków, jeśli chcesz. Jest to podobne do tego, w jaki sposób TypeScript i JavaScript współistnieją w mojej głowie.
Zdecydowanie użyłbym Caliburn.Micro w każdym nowym projekcie WPF, nad którym pracuję w przyszłości, jeśli miałbym szansę.
Komentarze
- Dziękuję za odpowiedź. Dwa lata później znacznie łatwiej było ” zaakceptować ” te frameworki po zrozumieniu koncepcji kontenerów wstrzykiwania zależności, której nauczyłem się z znakomity Mark Seeman ' s ” DI w .NET ” książka.
Odpowiedź
Dla każdego, kto przybywa tutaj z frustracji Caliburn.Micro, spójrz na ten framework: Stylet
Jest inspirowany przez Caliburn.Micro, z wyjątkiem tego, że usuwa wiele magii, która pozostawia Cię zdezorientowanym co do tego, co się dzieje. Dodatkowo dokumentacja jest napisana prostszym językiem bez zakładania, że chcesz przebrnąć przez techniczny żargon. Znacznie lepsze dla początkujących.
Ponadto Stylet przyjmuje 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 z wzorami, prawdopodobnie uznasz podejście ViewModel-First za bardziej naturalne, ponieważ zakłada ono, że twoja logika powinna sterować systemem, a nie widokiem.
EventAggregatordo przesyłania wiadomości, aNotificationObjectdo a ViewModelBase i MVVM Light ' sRelayCommanddla poleceń. Ważne jest, aby zidentyfikować problemy, które framework ma rozwiązać, i używać tylko tych rozwiązań. Nie ' nie czujesz, że ' jesteś zmuszony do korzystania z całej biblioteki frameworka.RelayCommand(ponieważ ” wiąże ” bezpośrednio z metodami według konwencji, zamiast wiązać się z właściwościami ICommand).RelayCommandz innej biblioteki, jeśli ta używana przez Caliburn Micro nie działa dla Ciebie.