Kwalifikacja: INF.04 - Projektowanie, programowanie i testowanie aplikacji

Wiele osób myli zadania widoku w architekturze MVVM z innymi warstwami, przez co później pojawiają się spore problemy przy rozwijaniu i utrzymywaniu większych aplikacji. Przede wszystkim, widok nigdy nie powinien zarządzać logiką aplikacji ani implementować algorytmów – to zadanie Modelu lub ewentualnie ViewModelu. Przenoszenie takich odpowiedzialności do UI prowadzi do tzw. „smrodu kodu” i utrudnia refaktoryzację czy testowanie. Spotkałem się w praktyce z projektami, gdzie próbowano do widoku wrzucić obsługę serwisów, walidację czy sterowanie workflow – efektem był totalny chaos. Równie często pojawia się błędne przekonanie, że widok powinien przekazywać dane do widoku i wymieniać informacje z modelem – tymczasem w MVVM przepływ danych realizuje głównie ViewModel dzięki data bindingowi, a widok jest raczej pasywny i nie zarządza wymianą informacji bezpośrednio z modelem. To ViewModel łączy model z warstwą prezentacji, pozwalając na luźne powiązanie i wysoką elastyczność. Kolejna mylna koncepcja dotyczy przechowywania pobranych i przetworzonych informacji – tym zajmuje się Model, ewentualnie ViewModel, a nie widok. Wrzucając takie rzeczy do UI, łamiemy zasadę separacji odpowiedzialności. Moim zdaniem, warto zapamiętać, że długofalowy rozwój systemu, możliwość testowania oraz opcja łatwego podmieniania warstw bez ruszania całej reszty zależą właśnie od tego, jak precyzyjnie trzymamy się podziału ról. MVVM został zaprojektowany po to, żeby każda warstwa miała jasno określone zadania – i tylko wtedy architektura ma sens, jeśli się tego trzymamy. Odpowiedzialności widoku ograniczają się do prezentacji i obsługi interakcji użytkownika; wszystko, co wykracza poza to, powinno być delegowane do innych warstw. To pozwala na czysty kod i zgodność z najlepszymi praktykami programistycznymi.