Elementy MVC

Skoro wiemy już, czym jest MVC i dlaczego stosowany jest do tworzenia aplikacji internetowych, przyjrzyjmy się bliżej poszczególnym jego składnikom.

Model

Model jest częścią MVC, odpowiedzialną za tzw. logikę biznesową. Termin logika biznesowa odnosi się do funkcjonalności związanej ze sposobem, w jaki aplikacja przechowuje dane.

Model powinien być jedyną częścią aplikacji, która przechowuje dane w sposób trwały. Sposób przechowywania tych danych jest tutaj zupełnie obojętny - może to być baza danych, pliki tekstowe, Web Services, itd. Ważne jest, aby szczegóły implementacyjne związane ze sposobem, w jaki Twój model przechowuje dane, były ukryte przed resztą aplikacji. Model powinien dostarczać innym komponentom spójnego interfejsu do przetwarzania tych danych i ukrywać implementację - np. zapytania SQL.

Dobrym sposobem implementacji modelu jest utworzenie oddzielnej klasy dla każdego logicznego obiektu. Typowe przykłady to:

• Użytkownicy
• Artykuły
• Koszyk (w sklepie internetowym)

Taka klasa może wykorzystywać wzorzec Singleton i powinna zawierać metody pozwalające na wykonywanie wszystkich operacji na związanych z nią danych, wymaganych przez resztę aplikacji.

Najczęściej model będzie przechowywał informacje w bazie danych. W takim przypadku przeważnie jedna klasa modelu odpowiada jednej tabeli w bazie danych, lub grupie ściśle powiązanych tabel. W przypadku konieczności zmiany jednej z tabeli, zmiany w kodzie PHP ograniczają się do modelu, a nawet do jednej klasy modelu. Dobrze zaprojektowany model powinien być odporny na takie wewnętrzne zmiany, tzn. zmiany w strukturze bazy danych nie powinny wpływać na interfejs, z którego korzystają pozostałe części aplikacji.

Dobrze zaprojektowany model powinien również być przenośny. Jeżeli mamy zaimplementowane klasy modelu służące do obsługi użytkowników (logowanie, administracja, itd.), możemy łatwo przenieść ten kod do innej aplikacji, która również wymaga takiej funkcjonalności. I to nawet nie metodą "kopiuj - wklej", tylko przenosząc bez zmian gotowe klasy.

Widok

Widok jest częścią aplikacji odpowiedzialną za wyświetlanie danych użytkownikom. Innymi słowy, widok odpowiada za prezentację. W przypadku aplikacji internetowych, najczęściej używanym formatem wyjściowym jest oczywiście HTML, ale widok nie musi ograniczać się tylko do niego. Równie dobrze aplikacja może prezentować wyniki w postaci XML, WML, obrazków, plików PDF i w wielu innych formatach. PHP ma wyjątkowo bogate możliwości w tym zakresie: szablony, XSLT, biblioteki do generacji obrazków, PDF lub Flasha...

Widok powinien wykorzystywać model do pobrania danych, które będą wyświetlone. Typowo, widok powinien utworzyć instancje klas modelu i wywołać metody odpowiedzialne za pobranie odpowiednich danych. Tym, czego należy się wystrzegać w widoku, jest modyfikacja danych. Widok nie powinien zmieniać w żaden sposób stanu aplikacji. Powinien np. wyświetlać listę użytkowników, ale nie powinien ich dodawać ani usuwać.

Widok jest prawdopodobnie łatwy do zrozumienia dla osób używających szablonów. W obu przypadkach celem jest oddzielenie logiki prezentacyjnej od logiki biznesowej. Należy jednak pamiętać, że widok nie jest szablonem (lub raczej zbiorem szablonów). Widok to przede wszystkim kod, który "wyciąga" z modelu potrzebne dane, natomiast nic nie stoi na przeszkodzie, aby widok wykorzystywał wewnętrznie szablony.

Widok również może być implementowany w postaci wielu klas, po jednej na każdą stronę, jeden dokument PDF, jeden plik XML, itd. W dobrze zaprojektowanej aplikacji widok powinien być "wymienny": zmiana formatu wyświetlanych danych (np. z HTML do PDF) powinna być osiągalna przez prostą wymianę klas widoku. Ma to obecnie coraz większe znaczenie, ponieważ od aplikacji zaczynamy wymagać obsługi formatów wyjściowych innych niż tradycyjny HTML, takich jak:

• PDF do drukowania
• RSS do newsów
• WML dla użytkowników telefonów
• SOAP i XML-RPC dla implementacji Web Services

Wraz z rozwojem informatyki będą pojawiały się nowe technologie wyjściowe, które nasza aplikacja powinna wspierać.

Sterownik

Sterownik jest sercem aplikacji wykonanej w technologii MVC. Sterownik powinien być częścią świadomą żądania HTTP. Na podstawie analizy żądania Sterownik powinien zdecydować, jakie akcje należy wykonać i jaki widok wyświetlić. Sterownik jest również zasadniczą częścią każdej biblioteki implementującej MVC. Widok i model muszą być dostosowane do specyfiki Twojej aplikacji (czyli prawdopodobnie napisane przez Ciebie), ale sterownik w zasadzie pozostaje bez zmian, więc nie ma potrzeby wyważać drzwi otwartych przez kogoś innego.

Sterownik w aplikacji jest tylko jeden, więc naturalnym rozwiązaniem w PHP jest jeden skrypt, który używa parametrów zawartych w URLu lub w danych POST, aby wybrać widok. Typowy adres będzie więc miał postać index.php?widok=ListaUżytkowników. Alternatywnie, można używać mod_rewrite lub innych podobnych mechanizmów, aby uzyskać np. URL postaci index.php/ListaUżytkowników.

Sterownik musi w jakiś sposób wiedzieć, co składa się na widok i model w Twojej aplikacji, oraz co należy wykonać w odpowiedzi na żądanie HTTP. W tym celu trzeba go jakoś skonfigurować. Jeżeli piszemy sterownik samemu, możemyumieścić te mapowania bezpośrednio w kodzie, ale rozwiązanie to jest nieelastyczne i oczywiście odpada w przypadku wykorzystania gotowego sterownika. Na ogół będziemy więc mieli plik konfiguracyjny, w którym napisane będzie, co należy wykonać w odpowiedzi na każde możliwe żądanie. Format tego pliku zależny jest od implementacji.

Jeżeli aplikacja ma wyświetlić listę użytkowników, sprawa jest prosta: sterownik tworzy odpowiedni widok, który z kolei pobiera z modelu odpowiednie dane i prezentuje np. w postaci tabelki. Ale co zrobić, gdy mamy dodać nowego użytkownika, a następnie wyświetlić listę? Widok, jak wiemy, nie może zmieniać modelu. Model może oferować niezbędną funkcjonalność, ale sam z siebie jej nie wywoła. Więc to sterownik musi obsłużyć dodawanie użytkowników, czyli sprawdzić dane POST i wywołać odpowiednią metodę modelu.

W tym celu należy do sterownika wprowadzić akcje. Akcja jest to pojedyncza czynność wykonywana przez aplikację. Przykłady akcji to:

• Dodaj użytkownika
• Wyświetl artykuły
• Dodaj produkt do koszyka

Taka akcja może być implementowana jako klasa tworzona przez kontroler, wykonująca odpowiednie zadanie i przekazująca sterownikowi informację, jaki widok należy wyświetlić. Jeżeli twoja aplikacja musi zmienić coś w modelu (np. dodać użytkownika), właśnie akcja jest odpowiednim miejscem do tego.

Koncepcyjnie akcje są częścią sterownika. O ile główny "silnik" kontrolera może być wielokrotnie używany, o tyle akcje są już specyficzne dla aplikacji.