MVVM … czy nie ?

2
33

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.

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here