O co chodzi?

MVC jako wzorzec projektowy, ma za zadanie separować logikę aplikacji od prezentacji oraz od kontekstu jej uruchomienia (miejsca w aplikacji). Wyróżnione są w nim trzy byty: Model odpowiedzialny za logikę, Widok zarządzający prezentacją danych oraz Kontroler stanowiący punkt wejścia do modelu i widoku. Pomiędzy nimi określone są pewne relacje informujące nas o dozwolonych kierunkach komunikacji. Całość wygląda następująco:

Jak widać, model powinien być całkowicie niezależny od pozostałych elementów, co ma umożliwić jego swobodne testowanie w oderwaniu od wpływów interfejsu użytkownika. Kontroler zawsze zależy od obu elementów, gdyż to on ma prawo zdecydować, jakiego modelu i jakiego widoku użyć w danej sytuacji. Ostatnia strzałka, łącząca widok z modelem oznacza, że widok powinien pobierać wyniki z modelu. Rzecz wydaje się oczywista dla każdego...

MVC a sprawa frameworków

Wszystko komplikuje się, gdy przeniesiemy się na grunt frameworków PHP. Okazuje się, że część z nich, wliczając w to jeden z wiodących, Zend Framework, w rzeczywistości nie implementuje żadnego MVC, a jedynie coś, co ma udawać, że nim jest poprzez sprytny trick z nazwami. Popatrzmy, co oferuje nam ZF w poszczególnych warstwach...

1. Model - w zendowej nomenklaturze nie ma nawet takiego pojęcia. Mamy interfejs do komunikacji z bazą danych, mamy związany z nią prosty ORM i nic więcej. Jeśli chcemy mieć prawdziwe modele, musimy całą tę warstwę sobie zbudować ręcznie, a do niedawna sensowne rozmieszczenie własnych plików utrudniał nawet autoloader. Podobna sytuacja, tj. utożsamianie modelu z ORM-em, występuje w wielu frameworkach.
2. Widok - umniejszony do zwykłych szablonów PHP, które po prostu osadzają dane w kodzie i nie interesują się, skąd pochodzą.
3. Kontroler - specjalista od wszystkiego. Tutaj obsługujemy przychodzące żądanie, sprawdzamy dane wejściowe, obsługujemy formularze, przekierowujemy dane z modelu do widoku, czasem nawet doformatowywujemy je odpowiednio, konfigurujemy stronicowanie itp. itd.

Istotnie, ciężko nazwać to implementacją wzorca MVC, gdyż nie tylko rola dwóch pierwszych literek została znacząco zredukowana, ale także nie mamy między nimi żadnego formalnego połączenia.

Odmiany MVC

Na MVC opiera się obecnie bez mała połowa informatycznego świata, dlatego też z biegiem czasu powstało wiele wariantów tego wzorca. Oto kilka z nich:

1. Model-View-Presenter - od MVC różni się brakiem połączenia między widokiem, a modelem. Rolę kanału komunikacyjnego przekazującego dane z jednego do drugiego pełni tutaj warstwa zwana prezenterem, która pełni jednocześnie funkcję kontrolera.
2. Model-View-ViewModel - wzorzec wywodzący się z Microsoftu stworzony z myślą o nowoczesnych platformach interakcji z użytkownikiem. Pomiędzy modelem, a widokiem znajduje się warstwa ViewModel, czyli "model widoku" stanowiący rodzaj warstwy logicznej prezentacji, który zajmuje się także przekazywaniem danych z modelu. Można na to patrzeć jak na wyspecjalizowany kontroler. Niemniej, niektóre źródła wyróżniają kontroler jako kolejną, czwartą warstwę.
3. Aktywny MVC - w środowisku WWW, ze względu na budowę protokołu HTTP, implementuje się wyłącznie pasywny MVC. Wersja aktywna przejawia się w warstwie modelu, która może tutaj być inicjatorem pewnej akcji kontrolera. Stosowane jest to w sytuacjach, gdy dane mogą zostać zmienione zewnętrznie i system musi na to odpowiednio zareagować, odświeżając je. Ponieważ model nie może być zależny od kontrolera, powiadomienie realizowane jest dzięki wzorcowi Obserwator.
4. Presentation-Abstraction-Control - w tym wzorcu rozpatrujemy hierarchię agentów składających się z trójki elementów: prezentacji, abstrakcji oraz kontroli. Prezentacja oraz abstrakcja są od siebie oddzielone, podobnie jak w MVP, a komunikacja między nimi zachodzi wyłącznie poprzez warstwę kontroli. Ta sama warstwa odpowiada także za komunikację z podrzędnymi agentami oraz z agentem nadrzędnym. Taka struktura dobrze współpracuje z wielowątkowością - odpowiednio zaprojektowana aplikacja może dawać użytkownikowi wrażenie bardzo krótkiego czasu uruchamiania, gdyż warstwa prezentacji staje się dostępna przed ukończeniem inicjowania abstrakcji.
5. Hierarchiczny MVC - wzorzec zaprezentowany po raz pierwszy w artykule dla magazynu JavaWorld, którego autorzy nie byli świadomi, że od 13 lat istnieje PAC :). Pomimo to między tymi wzorcami jest pewna różnica. Ponieważ HMVC bazuje bezpośrednio na pierwowzorze, dopuszcza on jawną komunikację między widokiem, a modelem agenta.

Co skłoniło mnie do napisania wpisu?

Już od dłuższego czasu podejrzewałem, że z implementacjami MVC w popularnych frameworkach jest coś nie w porządku. Z jednej strony miałem elegancką definicję wzorca oraz jego zastosowanie w javowym Swingu, z drugiej aplikacje internetowe, gdzie w kontrolerach działo się trochę zbyt wiele rzeczy. Z braku czasu oraz potrzeby nie zgłębiałem się jednak w tę tematykę aż do dnia, gdy przyszło mi robić projekt na CMS-ie Joomla. Jak nietrudno się domyślać, byłem średnio zachwycony pomysłem pisania w systemie, który nie grzeszy jakością swojego kodu. Jakościowo rzeczywiście, najlepiej nie jest, ale zagłębiając się w artykuły poświęcone tworzeniu dla niego komponentów odkryłem, że wśród tego morza straszliwie niespójnego, przestarzałego i czasami niebezpiecznego kodu kryje się wzorcowa implementacja MVC, z niemal wzorcowym rozdzieleniem zadań między poszczególne litery. Takie odkrycia dają do myślenia, a przy okazji pokazują, że nie każde czarne jest czarne, a nie każde białe jest białe...

PS. Właśnie ten projekt + studia są winne małym opóźnieniom w publikacji drugiej części tekstu o unikodzie w PHP, ale mam nadzieję, że w przyszłym tygodniu uda się to nadrobić.

Powrót

Na Zyxist.com panuje swoboda wyrażania opinii oraz krytyki pod dowolnym adresem. Jedyny warunek: musi być ona kulturalna i rzeczowa. Na chamstwo, prostactwo lub jawne obrażanie kogokolwiek nie ma tu miejsca i takie komentarze są bardzo szybko usuwane. Jeśli zamierzasz polemizować z treścią wpisu, wpierw uważnie ją przeczytaj.