Model-View-Controller (MVC)
Main menu Next


3. Przegląd rozwiązań MVC


Model aplikacji implementuje się zwykle jako Enterprise Java Beans w J2EE lub obiekty DAO, które są odpowiedzialne za pobieranie i przechowywanie danych (w bazie danych, plikach tekstowych, innych serwisach lub jakichkolwiek innych miejscach). Warstwa Modelu ukrywa sposób przechowywania i pobierania danych przed innymi warstwami.

W dalszej części tego referatu skoncentruję się na sposobach podziału pozostałej części aplikacji na warstwy Widoku i Kontrolera.

Tylko servlety

Wadą tego rozwiązania jest to, że kod HTML-a jest zmieszany z kodem Javy, przez co kod staje się nieczytelny i bardzo ciężko modyfikowalny. Ponadto rozwiązanie to uniemożliwia współpracę projektanta strony z programistą, ponieważ albo programista bedzie musiał nauczyć się projektowania stron (i smaku graficznego), albo projektant stron będzie musiał uczyć się Javy...

Tylko JavaServer Pages (JSP)

JavaServer Pages są odpowiedzią Sun-a na ASP Microsoft-u. Ogólnie rzecz biorąc JSP jest to HTML (lub XML) z dodanymi: Problemy z używaniem tego rozwiązania są podobne jak dla rozwiązania z samymi servletami (mieszanina kodu HTML-a i Javy).

Java Model 1

Java Model 1 jest to metoda w której jako template engine używa się JSP i obiektów JavaBean. Strona JSP jest odpowiedzialna zarówno za odbieranie żądań, jak i prezentowanie wyników. Jednakże jest tutaj podział pomiędzy prezentacja wyników, a operowaniem na nich. Wszystkie operacje dostępu do danych są wykonywane za pośrednictwem JavaBeans. Model 1 jest odpowiedni dla prostych aplikacji. Przy dużych aplikacjach może on prowadzić do nadmiernej ilości zagnieżdżonego kodu Javy, odpowiedzialnego za odbieranie żądań, w JSP, co znakomicie utrudnia pracę projektantom stron.


Java Model 2

Model 2 jest rozbudową Modelu 1 o serwlet, który pełni funkcję kontrolera. Serwlet ten przetwarza żądania klienta (przeglądarki), buduje obiekty JavaBeans, które przekazuje odpowiednim stronom JSP. Strona JSP odpowiada jedynie za prezentację i nie zawiera sama w sobie kodu logiki programu. JSP jedynie odbiera obiekty JavaBeans wyprodukowane przez serwlet kontrolera.


Jakarta Struts

Struts jest popularną biblioteką powstałą w ramach projektu Apache/Jakarta, służącą do rozdzielenia warstwy prezentacji od kontrolera. Warstwa prezentacji budowana jest za pomocą stron JSP z dodatkowymi custom tagami, a funkcję kontrolera pełni wyspecjalizowany serwlet.

Korzystanie z biblioteki Jakarta Struts

Serwlet-kontroler odpowiedzialny jest za translacje zapytań HTTP na akcje. Akcja jest to obiekt podklasy klasy Action. Zawiera on funkcję perform(), która pobiera żądanie, zajmuje się nim, a następnie odpowieda lub przekierowywuje do innego obiektu Action (np. mamy obiekt loginAction, ktory dostaje login i haslo, sprawdza, czy są poprawne i może przekierować żądanie do mainAction.)

Struts posiada mechanizm obróbki danych przekazywanych przez formularze HTML-a. Możemy napisać obiekt JavaBean (podklasy klasy ActionForm) w którym Struts będzie automatycznie zapisywał dane z pobranego formularza, a następnie ten obiekt przekazywał naszemu obiektowi Action. Obiekt taki musi posiadać metody get i set dla odpowiednich pól formularza. W obiekcie tym możemy zdefiniować metodę validate(), która sprawdzi, czy dane pobrane z formularza sa poprawne (np. czy otrzymany przy logowaniu identyfikator ma długość większą niż 0).

Struts zawiera rownież dużą kolekcję custom tags. Zaprojektowane są one tak, aby umożliwić korzystanie z wbudowanych w Javę mechanizmów internationalization (różne języki). Wszystkie wiadomości mogą być pobierane z plików resource (jeżeli chcemy rozszerzyć aplikację na kolejny język, to po prostu dodajemy kolejny plik resource).

Aby połączyć to wszystko w całość, na końcu musimy napisać konfigurację w pliku XML-owym.