Jakarta Struts Framework

Wzorzec Model-View-Controller

Istotą szeroko stosowanego wzorca projektowego Model-View-Controller jest podział aplikacji(bądź pewnej warstwy aplikacji, w przypadku bardzo rozbudowanych systemów) na 3 elementy:

Model
View(Widok)
Controller(Kontroler)

Model

Zadaniem modelu jest generalnie przechowywanie informacji o stanie aplikacji. Rola modelu jest określona dosyć luźno, np. mogą ją odgrywać zarówno session beany realizujące skomplikowaną logikę biznesową jak i rzeczywiste klasy modelu(np. mapowane bezpośrdenio na bazę danych obiekty hibernatowe). Modelem może byc także wiele innych rzeczy które stanowią ujednolicenie, abstrakcję danych, z których korzysta aplikacja. Z jednego modelu może zazwyczaj korzystać wiele różnych widoków toteż nie powinien on w żaden sposób od nich zależeć.

Widok

Widok odpowiada za wyświetlanie informacji użytkownikowi i umożliwienie mu wprowadzania nowych danych. Widok sam w sobie nie przechowuje żadnego stanu, jedynie przekształca na określony, przyjazny dla użytkownika format informacje pochodzące z modelu. Z reguły sytuacja jest oczywiście bardziej skomplikowana, widoki mają różne podwidoki, odpowiadające za wyświetlanie różnych części modelu, ale mające pewne cześci wspólne.

Kontroler

Kontroler zarządza interakcją pomiędzy widokiem a modelem, to do niego są najpierw kierowane żądania i to on decyduje co z nimi zrobić, w szczególności:

Pobiera żadania generowane przez elementy widoku i na ich podstawie dokonuje aktualizacji własciwego modelu
Aktualizuje widoki, tak żeby obrazowały bieżący stan aplikacji

Większe systemy posiadają najczęściej wiele wyspecjalizowanych kontrolerów, które całościowo decydują o przepływie sterowania w aplikacji

MVC a J2EE

Wzorzec MVC, pomimo, że ma swoją genezę w projektach klasycznych aplikacji desktopowych z graficznymi interfejsami, z czasem zadomowił się w systemach realizowanych w technologii J2EE(która w pewnym sensie wymusza jego stosowanie). W klasycznej aplikacji J2EE widokiem najczęściej są strony jsp lub po prostu zwykłe strony html, rolę modelu mogą pełnić np. entity beany zaś kontrolerami są najczęsciej serwlety. Z powyższego widać, że to zaszycie wzorca MVC a architekturze J2EE nie jest do końca przejrzyste, w szczególności granica pomiędzy widokiem(jsp) a kontrolerem(serwlety) może się zacierać. Teoretycznie nic nie stoi na przeszkodzie, żeby za tworzenie widoków(choćby explicite generowanie kodu html) odpowiadały serlwety...co oczywiście jest dosyć brzydkim rozwiązaniem. Tutaj własnie okazuje się pomocny framework Struts, wymuszający na nas porządne MVC.

Dlaczego warto stosować MVC, dlaczego czasem może to być nieprzyjemne

Zalety

Architektura korzystająca ze wzorca MVC umożliwia łatwą zamianę interfejsu użytkownika w istniejącej aplikacji. Operacja taka wymaga wyłącznie wymiany składników typu Widok i/lub Kontroler, natomiast komponenty typu Model pozostają niezmienione. W ten sposób interfejs użytkownika może być także wzbogacany o alternatywne formy prezentacji danych i interakcji z użytkownikiem
Kolejną zaletą MVC jest możliwość niezależnego testowania modelu, np. za pomocą JUnitów. w sytuacji gdy nie istnieją jeszcze model ani kontroler, bądź też aplikacja jest bardzo złożona.
Do stosowania MVC zachęca też coraz większa liczba dostępnych na rynku frameworków narzucających implementację pewnych warstw i/lub całych aplikacji w oparciu o MVC. Dzięki gotowym architekturom implementacja naszych systemów może przebiegać szybciej(oczywiście o ile wcześniej opanujemy używane technologie), poza tym nie tworząc własnych rozwiązań, mniej energii stracimy na poprawianie błędów(najlepszym frameworkom, takim jak struts można raczej zaufać)

Co może zniechęcić

Zwykle zmiany modelu wymuszają konieczność zmian widoków i kontrolerów(ale tego, żę nie trzeba nic zmieniać w kodzie gdy zmienią się wymagania klienta raczej nie da się uniknąc...)
W przypadku niestosowania gotowych frameworków, być może dodatkowa praca(pisanie kodu) w celu zaimplementowania wzorca MVC, w przypadku stosowania frameworków, na początku, dodatkowa praca(przegryzanie się przez dokumantację, tutoriale itp.) w celu poznania nowych technologii.

Struts

Struts to szkieletowa implementacja warstwy interfejsu aplikacji J2EE, wymuszająca zastosowanie architektury MVC. Pierwszym autorem i pomysłodawcą Struts jest Craig McClanahan, który w 2000 roku udostępnił swój projekt Apache Software Foundation.

Idea

Jądrem Struts jest serwlet Action, który na podstawie deskryptora xml(zawierającego specyfikację akcji dla poszczególnych zdarzeń) kieruje żądania do odpowiednich klas je obsługujących(Klasy te są definiowane przez programistę i dziedziczą z klasy Action dostarczanej przez biblioteke Struts). W pliku web.xml definiujemy na jakie żądania ma reagować serwlet Action, zwyczajowo reaguje na wszystkie żądania HTTP, których adres URL posiada rozszerzenie .do

Gdy serwlet ActionServlet odbiera żądanie użytkownika, tworzy obiekt klasy obsługi żądań i wywołuje jego metodę execute() lub perform(). Zadaniem programisty jest implementacja jednej z tych metod w taki sposób, aby zwracały one obiekt klasy ActionForward, wskazujący stronę jsp, do której powinno zostać przekazane sterowanie. Implementując klasę obsługi żądań, programista posiada dostęp do: nagłówka żądania HTTP, parametrów wywołania, obiektów JavaBeans o zasięgu application/session/request, obiektu ActionForm(O ActionForm jest więcej w następnym paragrafie) opcjonalnie przekazanego przez serwlet ActionServlet, obiektu HttpResponse.

W celu propagacji parametrów wywołania aplikacji, programista tworzy klasy parametrów, dziedziczące z klasy ActionForm. Obiekty klas parametrów są automatycznie wypełniane parametrami wywołania pochodzącymi od użytkownika. Każdy parametr jest zapisywany w obiekcie ActionForm za pomocą metody setXXX(), gdzie XXX to nazwa parametru. Implementacja takich metod jest zadaniem dla programisty. Obiekt ActionForm jest tworzony przez ActionServlet, a po wypełnieniu danymi jest przekazywany do obiektu obsługi żądań (metoda execute()). Klasa parametrów nie zawiera kodu przetwarzania danych, a jedynie wspomniane akcesory, służące do odczytu odebranych parametrów wywołania. Klasy parametrów umożliwiają także łatwą przeprowadzania walidacji, czy prostych przekształceń na wprowadzonych danych.

Walidacja

W Struts istnieje możliwość zdefiniowania automatycznej walidacji wprowadzanych, poprzez formularze, danych. Aby tego dokonać należy

W plikach validation.xml i validation-rules.xml określić jakie pola jakich formularzy będą podlegały walidacji oraz podać ograniczenia nakładane na wartości występujące w tych polach(np. w postaci wyrażeń regularnych)
Dopisać w struts-config.xml informacje o ValidationPlugin, w szczególności podać scieżki do validation.xml i validation-rules.xml
Przy wpisach(w struts-config.xml) dotyczących poszczególnych akcji należy ustawić validation='true' przy tych akcjach, które mają przechodzić walidację, należy także podać wartość input(gdzie ma nastąpić przekierowanie w przypadku niepowodzenia walidacji)
Formularz powinien dziedziczyć po ValidatorForm

Tiles

Biblioteka tagów, umożliwiająca budowanie stron jsp z niezależnych fragmentów(za pomocą tagów insert umieszczających podstrony w wybranych miejscach ekranu). Zaletami tiles są przede wszystkim łatwość wprowadzania zmian(wystarczy zrobić to w dołączanych kawałkach) oraz wielokrotne wykorzystanie kodu stron.

Aplikacje tworzone z użyciem tiles moga być całkowicie pozbawione kodu html a skład poszczególnych wyświetlanych(przez Struts) widoków można wyspecyfikować w jednym pliku konfiguracyjnym tilesDefinition.xml W struts-config.xml, w przekierowaniach efektów akcji Struts podajemy wtedy nie rzeczywiste nazwy stron jsp, tylko nazwy definicji z pliku tilesDefinition.xml, informacje o położeniu tego pliku należy umieścić w web.xml

Jedną z ciekawych cech tiles jest mozliwość dziedziczenia pomiędzy definicjami, zmniejszająca ilość redundantnego kodu

Zalety i wady

Najpierw kilka w miarę oczywistych zalet technologii Struts

Wiele newralgicznych i podatnych na zmiany informacji(treści komunikatów, strony do wyświetlenia itp.) jest zapisanych nie w kodzie Javy a w xml-owych plikach konfiguracyjnych. Umożliwia to między innymi podmianę tych informacji bez konieczności ponownego kompilowania systemu, modyfikacje wymagają jedynie zmian w kilku dobrze znanych plikach.
Wsparcie dla walidacji wprowadzanych danych(po stronie serwera bezpośrednio w kodzie poprzez zastoswanie beanów Form).
Wspomniane wcześniej cechy wynikające wprost z ze wzorca MVC
Szeroka stosowalność w świecie, a co za tym idzie wsparcie, dokumentacja, liczne fora, tutoriale itp.
Zastosowanie Tiles umożliwia dodatkowo separację treści od sposobu w jaki ta treść ma być wyświetlana, dzięki temu czysto graficzna strona interfejsu może być tworzona całkowicie niezależnie.

Z wadami będzie trochę gorzej, Struts nie ma ich wielu ;-)

Jedną z wad jest konieczność opanowania całkiem sporej technologii.
W aplikacjach używających Strutsów dzieje się wiele dodatkowych zdarzeń, akcji, na które nie mamy wpływu(zachodzą w samym Frameworku), może stanowić to pewną przeszkodę w optymalizacji naszej aplikacji. Nie da się ukryć, że, prawdopodobnie,będzie ona działała nieco wolniej...

Alternatywy

Spring MVC

Spring MVC jest 'intefejsową' częścią coraz bardziej ostatnio popularnego frameworku Spring.

Aplikacje osadzone na Springu wykorzystują wzorzec dependency injection, są dzięki temu, łatwiejsze do testowania jednostkowego(Junitów)
Są z reguły o wiele bardziej skomplikowane niż Struts - dużo dodatkowych deskryptorów, przez to mniej nadają się do wykorzystania w mniejszych projektach

Java Server Faces

Częśc standardu J2EE, dobre wsparcie, dokumentacja
Autorem jest twórca Struts
Jeszcze nie do końca dojrzała technologia

Tapestry

Efektywne(gdy już się opanuje technologię)
Dużo wzorców HTML
Długi cykl wydawania kolejnych wersji
Skromna dokumentacja, niewiele przykładów

WebWork

Nieskomplikowana architektura, dość szybkie działanie
Niewielka popularność, uboga dokumentacja

Przykładowe zastosowanie Struts

Teraz zaprezentujemy przykładową aplikację korzystającą ze Struts.