MVVM … czy nie ?

2
503

To trochę zadziorne pytanie. Wzorzec MVVM znajduje zastosowanie w światku .NET w aplikacjach WPF/Silverligh (tak BTW, ciekawe czy ktoś jeszcze pracuje w tej technologii) i od niedawna również w mobilno-wieloplatformowym Xamarin FORMS.

Nie będę się zagłębiał w szczegóły wzorca – wszystko można przeczytać na wikipedii. MVVM daje nam przede wszystkim separację warstwy logiki biznesowej od warstwy prezentacyjnej. W przeciwieństwie do tego, co oferowały nam kiedyś narzędzia RAD jak np. Delphi (spoczywaj w pokoju 🙂 ) czy Windows Forms, nie mamy już mieszanki kodu obsługującego akcje GUI z kodem realizującym rzeczywistą logikę.

Otrzymujemy więc:

  • Niezależność kodu GUI (Xaml) od reszty, pozwalając innym osobom (np. UX-om) pracować nad tą warstwą aplikacji
  • Możliwość napisania testów dla praktycznie całości logiki, czy stosowania TDD

Sytuacja idealna, zawzięcie często broniona przez ortodoksów stosowania MVVM, jest taka, że w klasach code-behind nie ma być nic. Cała logika interakcji jest realizowana przez ViewModel.

Wróćmy jednak do pytania z tematu posta. MVVM – dlaczego nie ?

Dla osób, które już w tej chwili rozmyślają nad bezsensownością tego pytania nadmienię, że nie jestem przeciwnikiem MVVM. Stosuję go w moich aplikacjach. Używam go też w projekcie konkursowym Daj Się Poznać (w WPF i będę również w Xamarin FORMS). Nie namawiam do pisania spaghetti. Mam natomiast kilka przemyśleń w tym temacie i taka jest geneza tego posta.

Ortodoksyjne stosowanie tego wzorca prowadzi często do sytuacji wprost kuriozalnej. Weźmy chociażby kwestię otwarcia okna dialogowego, w sposób nie łamiący założeń wzorca. Zamiast użyć zwykłego ShowDialog(), trzeba napisać pierdyliard linii kodu, zaciemniając w ten sposób bez sensu projekt. Ile ludzi, tyle też metod w jaki sposób to poprawnie zrobić. Wystarczy zerknąć na StackOverflow tutaj lub tutaj. Zdania są nie rzadko nawet podzielone w kwestii co tak naprawdę łamie założenia wzorca a co nie. Podobnie jest też np. z zamykaniem okna.

Brak jednego rozwiązania tak banalnych i podstawowych funkcjonalności powoduje też ogromne problemy, gdy zetkniemy się z czymś takim w legacy code.

Ile razy zmagając się z jakąś operacją, którą łatwo moglibyśmy zrobić w code-behind, rozwiązanie które znajdujemy wymaga albo napisania (jak w przypadku okna dialogowego) sporej ilości kodu albo wręcz gruntownej przebudowy tego co już mamy.

Wspomóc możemy się frameworkami. Nie każdy ma przecież ochotę pisać własne implementacje RelayCommand. Do najpopularniejszych możemy zaliczyć MVVM Light i Prism. Prism jest potężną kobyłą, realizującą wiele zadań poza wspieraniem wzorca MVVM. MVVM Light jest lżejszy i do tego zadania dedykowany. Prism-a specjalnie nie używałem, MVVM Light za to znam całkiem nieźle. Frameworki rzeczywiście mocno ułatwiają pracę, ale nie załatwiają wszystkich problemów.

Ja nie jestem ortodoksem. Nie uważam, że code-behind musi zostać całkowicie czyste. Jeżeli piszę prostą aplikację lub narzędzie, którego okres żywota jest ograniczony owszem używam MVVM (bo dobre praktyki zawsze stosować warto), ale zwracam uwagę głównie na kod, którego przetestowanie jest istotne. Jeżeli coś wymaga zbyt dużo pracy, a nie jest istotne z punktu widzenia testów – olewam.

W złożonym systemie, który będzie istotnym narzędziem w środowisku produkcyjnym klienta i trzeba go będzie przez jakiś czas supportować, testy mają jednak dużo większą wagę. Nie mniej jednak pewne operacje związane z obsługą widoku, których testowanie nie ma specjalnie sensu robię po prostu tak, żeby było wygodnie. Nie zastanawiam się godzinami czy rozwiązanie, które przyjąłem łamie założenia MVVM czy nie.

Dlaczego tak ? Bo wzorce są przecież po to, żeby zestandaryzować pewne rozwiązania – a co za tym idzie ułatwić pracę. Podążanie dobrze wydeptaną i sprawdzoną drogą jest pewne i bezpieczne. Gorzej, gdy wzorzec nakreśla nam pewien zakres, który jest w pewnych kwestiach wolno interpretowalny, albo wprost – dodaje nam niczym nie uzasadnionej i bezsensownej roboty. Czy warto wtedy kruszyć kopię ? Moim zdaniem nie.

A co Ty o tym myślisz ? Chętnie podyskutuję na ten temat w komentarzach.

2 KOMENTARZE

  1. Rzadko spotykany głos rozsądku. Ale fanatyków i tak nie przekona – oni będą stosować “czysty” MVVM i TDD, nawet jeśli wydłuży to czas wykonania projektu o 300%…

    • Dzięki za komentarz :). Ostatnimi czasy hobbystycznie wracam do programowania na 8-bitach (ZX Spectrum) i dochodzę do wniosku, że zbudowaliśmy potworną wieżę babel wokół projektowania software-u i samego programowania. Oczywiście bezspornie systemy są teraz daleko bardziej skomplikowane niż wtedy, ale coraz częściej wydaje mi się, że kładziemy większy nacisk na wszystko co do okoła a nie na sam kod a ludzie pasjonują się nie samym programowaniem ale całą tą sztucznie wydmuchaną otoczką. Z drugiej strony, całkiem często zdarza mi się wprowadzać poprawki lub modyfikacje w już istniejącym kodzie i często jak otworzę projekt po raz pierwszy to ręce opadają …. i zaczynam się zastanawiać czemu to wszystko służy. Żeby nie było – nie mam nic przeciwko MVVM i TDD czy DDD, ale to ma służyć czemuś konkretnemu, a nie być samym dla siebie w imię tego, że jest modne.

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here