Web frameworks do budowy aplikacji zgodnych z J2EE

Web frameworks do budowy
aplikacji zgodnych z J2EE
Jacek Panachida
Cel pracy
●
●
Analiza wybranych ram projektowych
dostępnych dla platformy Java
Warunki selekcji
–
napisany z wykorzystaniem języka Java oraz
platformy J2EE
–
otwarty kod źródłowy
–
licencja zaaprobowana przez organizację Open
Source Initiative
Sposób realizacji
●
●
●
Budowa aplikacji wspomagającej pracę
przychodni weterynaryjnej (Petclinic)
Celem aplikacji jest sprawdzenie badanych
bibliotek w praktycznym użyciu
Aplikacja nie jest nastawiona na funkcjonalność
lecz na pokazanie możliwości badanych bibliotek
Analiza
●
Podczas analizy zostaną uwzględnione kwestie
związane z
–
teoretycznymi zasadami działania biblioteki
–
badaniem gotowej aplikacji
Porównanie - część teoretyczna
●
Zakres części teoretycznej porównania
–
architektura
–
model programistyczny
–
cykl życia żądania/zdarzenia
–
nawigacja
–
walidacja i konwersja typów
–
internacjonalizacja
–
łatwość testowania
–
rozszerzalność
Porównanie – część praktyczna
●
Zakres części praktycznej porównania
–
wydajność
–
metryki kodu
●
●
kodu języka Java
kodu szablonów
–
wsparcie społeczności
–
dojrzałość
–
dostępność (ang. accessibility)
–
łatwość wprowadzania zmian (ang. changeability)
Standardy
●
●
Charakterystykę wymagań niefunkcjonalnych
obejmuje norma ISO 9126
Dostępność definiowana jest przez standard
WAI (Web Accessibility Initiative)
Mnogość możliwości
●
●
Obecnie istnieje ponad 40 różnych szkieletów
programistycznych przeznaczonych do budowy
aplikacji internetowych
Najpopularniejsze
–
Struts
–
JavaServer Faces
–
Spring Web MVC
–
WebWork
–
Tapestry
–
Struts2 (WebWork + Struts)
Klasyfikacja
●
●
Ze względu na implementowany model
–
Model 1
–
Model 2
–
Model komponentowy
Ze względu na zakres działania
–
specjalizowane
–
kompleksowe (ang. full-stack)
Model 1 (rys)
Model 2 (rys)
Zadania szkieletów programistycznych
●
Mapowanie nadchodzących żądań do kontrolerów
●
Nawigacja
●
Dostęp do warstwy modelu, walidacja
●
Integracja z językiem znaczników
●
Internacjonalizacja i lokalizacja
●
Obsługa alternatywnych technologii widoku
●
Zmiana motywów graficznych
Analizowane biblioteki
●
●
Tworzona praca dotyczy dwóch bibliotek
–
Spring Web MVC
–
JavaServer Faces
Uzasadnienie
–
realizacja odmiennych modeli
–
popularność
Podział aplikacji na moduły
Elementy dodatkowe
●
Rozwiązania alternatywne
●
Wzorce projektowe
●
Środowisko pracy
Rozwiązania alternatywne
●
Aplety
●
Java Web Start
●
RIA (Rich Internet Application)
–
Adobe Flex
–
Laszlo
–
Echo
Wzorce projektowe warstwy
prezentacji
●
Front Controller
●
View Helper
●
Model-View-Controler (MVC)
Front Controller
●
Cel
–
●
●
centralne zarządzania widokami w pojedynczym
obiekcie przyjmującym żądania klientów
Motywacja
–
ułatwienie wyboru widoku dla żądania, autoryzacja
–
poprawa zarządzania i separacji ról
Zastosowanie
–
aplikacja posiadająca skomplikowaną nawigację
–
aplikacje wymagające zastosowania polityki
bezpieczeństwa
Front Controller (rys)
View Helper
●
Cel
–
●
●
oddzielenie widoku od logiki związanej z jego
przetwarzaniem
Motywacja
–
podział zespołu projektowego
–
separacja ról (brak logiki w kodzie widoku)
Zastosowanie
–
aplikacje zawierające skomplikowaną logiką
związaną z prezentacją
View Helper (rys)
Model-View-Controller
●
Cel
–
●
●
definicja podstawowych, niezależnych od siebie
części aplikacji
Motywacja
–
rozdzielenie ról
–
podział zespołu projektowego
Zastosowanie
–
duże, skomplikowane aplikacje cechujące się
elastycznością
Model-View-Controller (rys)
Środowisko pracy (1)
●
Narzędzia wytwarzania
–
Subversion
●
–
Maven
●
–
translator obiektowo-relacyjny
Spring
●
–
wspomaganie w zarządzaniu projektem
Hibernate
●
–
system wersjonowania
szkielet programistyczny warstwy środkowej
Eclipse
●
zintegrowane śrdowisko programistyczne
Środowisko pracy (2)
●
Narzędzia testujące
–
Spring Mock (baza danych)
●
–
EasyMock
●
–
wspracie dla obiektów pozornych
JUnit 4
●
–
transakcyjne testowanie warstwy DAO
testy jednostkowe
Selenium
●
testy akceptacyjne, działające na poziomie przeglądarki