Pasywny widok, czyli MVC w środowisku eventowym

     Tak jak zapowiedziałem w poprzednim wpisie, chciałbym zaproponować architekturę aplikacji opartych na Windows Forms (lub na innym środowisku eventowym, np. na Javowym Swingu), która rozdzieli prezentację od logiki oraz umożliwi testowanie jednostkowe.

     Ktoś, kto na co dzień pisze aplikacje webowe może się w tym miejscu zdziwić, bo przecież w kontekście aplikacji webowych oczywistą oczywistością jest to, że jeśli chce się rozdzielić logikę od prezentacji należy zastosować klasyczny wzorzec projektowy MVC. Dlaczego nie jest tak w przypadku aplikacji okienkowych? Żeby to wyjaśnić, przypomnę, jak działa aplikacja webowa stosująca MVC.

     Do serwera przychodzi żądanie HTTP. Na podstawie adresu URL budowany jest odpowiedni kontroler, a na podstawie parametrów (najczęściej zawartych w żądaniu HTTP POST) budowany jest model. Następnie model jest przekazywany do kontrolera, który zmienia jego stan, a potem przekazuje model do widoku. Widok buduje od zera swoją zawartość na podstawie stanu modelu. Na koniec zbudowany widok jest odsyłany do klienta, a aplikacja może "wyrzucić do śmieci" wszystkie obiekty utworzone do obsłużenia żądania.

     Taki cykl życia nie nadaje się zupełnie do aplikacji okienkowych, bo musielibyśmy po każdym najdrobniejszym kliknięciu budować i renderować od zera całą warstwę prezentacji. Martin Fowler opisał na swojej stronie wzorzec Passive View (Pasywny widok), który jest wersją MVC nadającą się do aplikacji okienkowych.
     Wzorzec jest bardzo ciekawy, ale wg mnie, sposób w jaki pan Fowler go opisał jest dość zagmatwany, a przedstawione diagramy UML są dla mnie nieczytelne. Osobiście preferuję przedstawianie wzorców projektowych za pomocą działającego kodu i właśnie dlatego postanowiłem napisać prostą aplikację demonstrującą pasywny widok. Można ją pobrać stąd.
     Aplikacja jest bardzo prosta: wpisujemy imię i nazwisko w pole tekstowe, a gdy napis nie składa się z dwóch słów rozpoczynających się z dużych liter, to wyświetlany jest komunikat o błędzie.

     Jeśli chodzi o architekturę, to cały trick polega na tym, że klasa-widok nie wykonuje sama żadnych czynności i nie ma żadnych pól (nie licząc wygenerowanych przy użyciu Designera pól wizualnych kontrolek). W szczególności widok nie wie nic o modelu - i to jest zasadnicza różnica w stosunku do webowego MVC. Do kodu widoku dodaje się tylko settery i metodę podpinającą metody obserwujące zdarzenia na widoku (należące do kontrolera).
     Natomiast kontroler powinien być napisany tak, żeby mógł działać poprawnie nawet, gdy nie ma żadnej wizualnej reprezentacji. Dzięki temu można go przetestować jednostkowo, a to jest bardzo duża zaleta. W tym miejscu przypomniała mi się sytuacja, gdy mój przełożony robił złączenie dwóch rozgałęzień na SVNie i gdy przy niektórych ważnych kontrolkach pojawił się napis "merged" powiedział, że przydałaby mu się wódka na odwagę przed wrzuceniem złączonego kodu "na produkcję". Gdyby miał do dyspozycji testy jednostkowe złączonych klas, mógłby je odpalić i już by wiedział, czy złączenie było wykonane poprawnie.
     Do omówienia został jeszcze tylko model. Jest on najprostszym elementem tej układanki. Jedyne, o czym warto napisać, to że dobrze jest napisać model w oparciu o wzorzec Obserwator, czyli niech model powiadamia o zmianach swojego stanu, dzięki czemu kontroler nie musi sprawdzać go w sposób czynny.