MVC (Model-view-controller) jest tzw. wzorcem projektowym, stosowanym przy

Transkrypt

1 Wprowadzenie do MVC Co to jest MVC? MVC (Model-view-controller) jest tzw. wzorcem projektowym, stosowanym przy tworzeniu nowoczesnych systemów informatycznych. Główną koncepcją MVC jest wymuszenie podziału aplikacji na 3 niezaleŝne warstwy reprezentujące kolejno: (Model) Model danych - opis struktur danych i powiązań pomiędzy nimi (View) Interfejs, czyli to co widzi uŝytkownik (Controller) Logika działania - powiązania między zdarzeniami zachodzącymi w systemie Podział na warstwy słuŝy uporządkowaniu architektury systemu. Dzięki temu, Ŝe kaŝda logiczna część jest od siebie oddzielona, zmiana w jednym miejscu, nie powoduje konieczności wykonywania lawinowej ilości zmian w innych miejscach systemu. Mimo, Ŝe istnieje wiele frameworków wspierających MVC w innych technologiach, J2EE wiedzie zdecydowany prym jeŝeli chodzi o ilość sprawdzonych narzędzi zapewniających implementację oprogramowania zgodnego z wzorcem MVC. Do najbardziej popularnych naleŝą: JSF, Spring oraz Struts. Rys historyczny MVC nie jest pomysłem nowym. Wymyślony został w laboratoriach PARC (Palo Alto Research Centre) firmy Xerox (tych samych, którym zawdzięczamy m. in. myszki i systemy okienkowe) juŝ w latach siedemdziesiątych. Wtedy oczywiście nikt nawet nie myślał o wykorzystaniu wzorca do aplikacji internetowych. MVC został wykorzystany do zaprojektowania interfejsu uŝytkownika w języku Smalltalk, stworzonym zresztą równieŝ przez PARC. To, co nas jednak interesuje, to zastosowanie MVC w aplikacjach internetowych. Tego kroku dokonał Sun na potrzeby Javy. Java pełni tutaj rolę szczególną równieŝ dlatego, Ŝe najbardziej znana implementacja MVC powstała właśnie dla Javy. Tym projektem jest Struts, stworzony przez Apache Jakarta Project. Struts nie jest jedyną słuszną implementacją MVC, ale na pewno najbardziej popularną i w pewnym sensie referencyjną.

2 W rozwaŝaniach nad MVC przewijają się równieŝ pojęcia Model 1 i Model 2. Pochodzą one ze specyfikacji JSP i J2EE. Model 1 był podejściem, w którym logika biznesowa była umieszczona w modelu, ale widok rozrzucony był po poszczególnych stronach, bez centralnego kontrolera. Model 2 natomiast jest w zasadzie tym samym co MVC, dlatego w kontekście aplikacji internetowych te dwa pojęcia mogą być uŝywane zamiennie. 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 lub Java 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.

3 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. MoŜna na przykład wykorzystać język PHP, który ma bogate moŝliwości w tym zakresie: szablony, XSLT, biblioteki do generacji obrazków, PDF lub Flasha; moŝna wykorzystać strony pisane w JSP. 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, a przy programowaniu w Javie jeden serwlet, który uŝywa parametrów zawartych w URLu lub w danych POST, aby wybrać widok. Typowy adres będzie więc miał postać

4 index.jsp?widok=listauŝytkowników. Alternatywnie, moŝna uŝywać mod_rewrite lub innych podobnych mechanizmów, aby uzyskać np. URL postaci index.jsp/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 skonfigurować. JeŜeli piszemy sterownik samemu, moŝemy umieś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. Kiedy uŝywać MVC? śadne rozwiązanie nie jest uniwersalne. Podobnie MVC nie nadaje się do kaŝdej aplikacji. JeŜeli mamy do czynienia z prostym skryptem wytwarzanym metodą "napisz i zapomnij", zalety MVC nie będą równowaŝyć kosztów. Zyski wynikające ze stosowania tego wzorca - jak zresztą i innych "dobrych praktyk programowania" - są znaczące gdy: aplikacja jest duŝa i skomplikowana aplikację trzeba będzie utrzymywać i dostosowywać do nowych potrzeb w wytwarzanie zaangaŝowanych jest wiele ludzi, którym trzeba wyznaczyć obszary kompetencji zamierzamy wykorzystać fragmenty aplikacji (np. klasy modelu) w innych projektach

5 Krótko o wzorcach projektowych MVC jest wzorcem projektowym. Dla osób, które nie miały jeszcze styczności z wzorcami, postaram się krótko wyjaśnić, w czym rzecz. Wzorzec projektowy jest kolekcją obiektów i powiązań między nimi, wymyśloną, opisaną i wielokrotnie sprawdzoną, przeznaczoną do efektywnego rozwiązywania pewnego problemu. JeŜeli problem, który musisz rozwiązać, jest podobny do problemu rozwiązywanego przez jeden ze znanych wzorców, moŝesz zaoszczędzić sporo pracy wykorzystując ten wzorzec w swoim kodzie. Wzorzec nie jest gotowym kodem. Kod w dalszym ciągu musisz sam napisać, ale będziesz mógł oprzeć się na sprawdzonym i dobrze udokumentowanym rozwiązaniu. Wzorców projektowych jest wiele, tak jak wiele jest powtarzających się problemów, które wzorce rozwiązują. Model - Widok - Sterownik jest właśnie jednym z takich wzorców, który szczególnie nadaje się do rozwiązywania szczególnej klasy problemów: jak dobrze zaprojektować aplikację internetową. Generalnie, przepływ sterowania w aplikacji MVC przybiera dwie postacie: uŝytkownik Ŝąda wyświetlenia określonego widoku (np. lista uŝytkowników) uŝytkownik wysyła dane i oczekuje zmiany stanu aplikacji (np. dodania uŝytkownika) Pierwszy, prostszy przypadek ilustruje schemat: 1. śądanie uŝytkownika (czyli Ŝądanie GET od przeglądarki) trafia do kontrolera. 2. Sterownik określa, który widok jest odpowiedni dla tego Ŝądania, tworzy obiekt widoku i przekazuje mu sterowanie. 3. Widok tworzy potrzebne mu klasy modelu i prosi go o podanie niezbędnych danych 4. Model wysyła zapytanie do bazy danych. 5. Baza danych zwraca modelowi odpowiednie dane. 6. Model zwraca dane widokowi. 7. Widok formatuje dane i wysyła uŝytkownikowi w postaci HTML. Drugi przypadek jest trudniejszy, poniewaŝ jest więcej pracy do wykonania: 1. śądanie uŝytkownika (tym razem na ogół Ŝądanie POST) trafia do kontrolera. 2. Sterownik określa, Ŝe obsłuŝenie Ŝądania wymaga wykonania akcji, tworzy obiekt odpowiedniej akcji i przekazuje sterowanie. 3. Akcja sprawdza dane zawarte w POST, po czym tworzy potrzebne jej klasy modelu i prosi o zmianę danych. 4. Model zmienia zawartość bazy danych. 5. Akcja informuje sterownik o zakończeniu przetwarzania i podaje, jaki widok naleŝy wyświetlić. 6. Sterownik tworzy odpowiedni obiekt widoku i przekazuje sterowanie. 7. Widok tworzy potrzebne mu klasy modelu i prosi go o podanie niezbędnych danych 8. Model wysyła zapytanie do bazy danych. 9. Baza danych zwraca modelowi odpowiednie dane. 10. Model zwraca dane widokowi. 11. Widok formatuje dane i wysyła uŝytkownikowi w postaci HTML.

6 Po co uŝywać MVC? To, Ŝe MVC jest wzorcem projektowym, samo w sobie nie oznacza, Ŝe mamy go stosować pisząc kolejną aplikację. Powodem jest to, Ŝe MVC idealnie wpasowuje się w specyfikę zastosowań. KaŜde Ŝądanie nowej strony jest interakcją uŝytkownika z systemem i musi zostać jakoś przetworzone (kontroler). Większość aplikacji musi przechowywać dane w sposób trwały - najczęściej w bazie danych (model). I wreszcie dane te muszą zostać wyświetlone w jakiś sposób, lub raczej na wiele róŝnych sposobów (widok). Model - Widok - Kontroler odpowiada tym podstawowym potrzebom. KaŜda z części składowych wzorca ma ściśle zdefiniowane zadanie, jak na rysunku: Podstawową zaletą MVC jest modyfikowalność. Podstawowym problemem w utrzymywaniu skomplikowanych aplikacji jest konieczność wprowadzania zmian. Byle jak napisana aplikacja jest w zasadzie niemodyfikowalna. KaŜda zmiana moŝe generować nowe błędy. Odpowiedzią na to jest - ogólnie rzecz biorąc - podejście obiektowe i hermetyzacja. MVC właśnie hermetyzuje poszczególne części aplikacji. JeŜeli zachodzi konieczność zmiany struktury bazy danych, lub wymiany całej bazy, wystarczy zmienić kod modelu. Mamy pewność, Ŝe nie będzie to miało wpływu na inne części aplikacji. JeŜeli trzeba zmienić wygląd stron, lub zmienić technologię generowania wyników (np. przejść na szablony w aplikacji, która ich na razie nie wykorzystuje), zmiany ograniczają się do klas widoku. Literatura: 1. "Podstawy programowania w Javie", Krzysztof Barteczko. 2. Artur Tylach, Tutorial "Java - nowy standard programowania w Internecie" 3. BruceEckel, "Thinking In Java", wydawnictwo Helion. 4. "Tomcat: The Definitive Guide", Jason Brittain, Ian F. Darwin, O'Reilly & Associates (2003) 5. "Tomcat Kick Start", Martin Bond, Debbie Law Sams (11/2002) 6. "Professional Apache Tomcat 6", Vivek Chopra, Sing Li, Jeff Genender, Wrox Press (2007) 7. "Model View Controller MCV", Jeff Moore,