Projektowanie aplikacji Java EE
advertisement
Wielowarstwowe aplikacje internetowe Plan wykładu • Projektowanie warstwy prezentacji – sesja, kontrola dostępu, duplikacja, walidacja Projektowanie aplikacji Java EE • Złe praktyki w warstwie prezentacji • Projektowanie warstwy biznesowej – komponenty sesyjne, komponenty encyjne • • • • Złe praktyki w warstwie biznesowej Refaktoryzacja warstwy prezentacji Refaktoryzacja warstwy biznesowej Wzorce projektowe JavaServer Faces (JSF) Zarządzanie sesją • Sesja: konwersacja łącząca wiele żądań i odpowiedzi przesyłanych między klientem i serwerem • Stan sesji po stronie klienta HTTP – ukryte pola formularza HTML – cookies Kontrola dostępu klienta • Ochrona widoku – – – – Mechanizm ochrony "wszystko albo nic" Dołączanie ochrony do fragmentów widoku Ochrona widoku na podstawie ról Ochrona przez konfigurację • Stan sesji w warstwie prezentacji – demarkacja sesji • Stan sesji w warstwie biznesowej i warstwie zasobów • Standardowe zasady bezpieczeństwa • Wykorzystanie katalogu /WEB-INF Duplikacja formularzy HTML • Walidacja po stronie klienta • Dwukrotne wysłanie formularza • Token synchronizujący (Déjà vu) – Język skryptowy umieszczony w widoku – Prosta walidacja: formaty, pola wymagane • Walidacja po stronie serwera formularz HTML TOKEN klient klient HTTP HTTP Walidacja TOKEN – Walidacja oparta na formularzu – Walidacja oparta na typach abstrakcyjnych serwer HTTP serwer HTTP TOKEN TOKEN klient klient HTTP HTTP serwer HTTP serwer HTTP Złe praktyki w warstwie prezentacji • Kod sterujący w wielu widokach • Udostępnianie struktur danych warstwy prezentacji warstwie biznesowej • Duplikacja formularzy • Użycie skryptletów w widoku • Znacznik <jsp:setProperty> Korzystanie z komponentów sesyjnych • • • • Komponenty sesyjne stanowe i bezstanowe Skalowalność i wydajność Wybór w zależności od procesu biznesowego Przechowywanie stanu sesji Korzystanie z komponentów encyjnych • Komponenty encyjne – – – – Obiektowy widok danych Transakcyjność Współdzielenie Odporność na awarie kontenera • Logika biznesowa w komponentach encyjnych – Brak logiki, metody dostępu do danych – Logika samowystarczalna obsługi własnych danych Refaktoryzacja • Cele refaktoryzacji – – – – – – Uproszczenie pielęgnacji aplikacji Poprawienie modułowości aplikacji Rozdzielenie ról członków zespołu projektowego Wielokrotne wykorzystanie komponentów Zwiększenie bezpieczeństwa Redukcja komunikacji sieciowej Złe praktyki w warstwie biznesowej • Mapowanie modelu obiektowego na model komponentów encyjnych • Mapowanie modelu relacyjnego na model komponentów encyjncyh • Korzystanie z komponentów encyjnych tylko do odczytu • Osadzanie usług wyszukiwania po stronie klienta • Rozdrabnianie komponentów encyjnych Wprowadzenie kontrolera Logika sterująca w jednej klasie sterującej która stanowi początkowe miejsce obsługi żądań klienta Wprowadzenie tokenu synchronizującego Współdzielony token monitoruje i steruje przepływem żądań i dostępem klientów do zasobów, wymuszając określoną kolejność żądań Ukrycie szczegółów warstwy prezentacji przed warstwą biznesową Wszystkie odwołania do struktur danych, klas i protokołów komunikacyjnych w warstwie biznesowej muszą być usunięte, dane między warstwami przesyła się za pomocą struktur ogólnych Podział logiki na niezależne fragmenty Logika biznesowa z widoków przeniesiona do jednej lub kilku klas pomocniczych, które są wykorzystywane przez widoki JSP lub serwlety Usunięcie konwersji z widoku Cały kod konwersji musi być przeniesiony z widoku do klasy pomocniczej Ukrywanie zasobów przed klientem (1) Najbardziej istotne zasoby powinny być ukryte i chronione przed użytkownikiem poprzez konfigurację kontenera Ukrywanie zasobów przed klientem (2) Zasoby mogą być chronione przez kontroler i klasę pomocniczą zawierającą definicje ograniczeń konfiguracja web.xml JSP kontroler klient HTTP kontroler klient HTTP warstwa prezentacji warstwa prezentacji Ukrycie komponentów encyjnych Jeżeli komponenty encyjne w warstwie biznesowej są udostępniane klientom w innych warstwach, to należy je ukryć za komponentami sesyjnymi logika biznesowa komponent encyjny Session Façade logika transakcyjna klient HTTP warstwa prezentacji lub klienta komponent encyjny warstwa biznesowa logika biznesowa klient HTTP warstwa prezentacji lub klienta logika transakcyjna warstwa biznesowa komponent encyjny komponent encyjny Wprowadzenie obiektów Business Delegate Komponenty sesyjne warstwy biznesowej powinny być dostępne w innych warstwach poprzez obiekty Business Delegate Łączenie komponentów sesyjnych Komponenty sesyjne reprezentują usługi biznesowe i nie odwzorowują komponentów encyjnych 1:1 Wydzielenie kodu dostępu do danych Cały kod dostępu do danych znajduje się w wydzielonej klasie pomocniczej zlokalizowanej logicznie i fizycznie blisko źródła danych Logika biznesowa w komponentach sesyjnych Logika biznesowa wyrażająca relacje między komponentami encyjnymi jest przeniesiona do komponentu sesyjnego Stosowanie puli połączeń Pula połączeń zawiera wcześniej zainicjalizowane połączenia z bazą danych Wzorzec • Każdy wzorzec składa się z trzech części, które wyrażają związek między konkretnym kontekstem, problemem i rozwiązaniem. Christopher Alexander • Wzorzec to pomysł, który okazał się użyteczny w jednym rzeczywistym kontekście i prawdopodobnie będzie także użyteczny w innym. Martin Fowler Cechy wzorca • • • • • • • Odkrywane dzięki doświadczeniu Zapisywane w formacie strukturalnym Zapobiegają wyważaniu otwartych drzwi Wykorzystywane wielokrotnie Obrazują najlepsze sprawdzone rozwiązania Nieustannie ewoluują Mogą być łączone by rozwiązywać bardziej złożone problemy • Wzorzec a strategia Podejście warstwowe źródło: "Core J2EE wzorce projektowe", D.Alur, J.Crupi, D.Malks Mapa wzorców projektowych źródło: www.corej2eepatterns.com Intercepting Filter Intercepting Filter • Problem: przechwycenie i modyfikowanie żądania, odpowiedź przed i po przetwarzaniu • Siły – Scentralizowane przetwarzanie żądań – Niezależne komponenty do przetwarzania wstępnego • Rozwiązanie – Standardowy filtr javax.servlet.Filter • Konsekwencje – Poprawa wielokrotnego użycia – Elastyczność konfiguracji – Koszt wymiany danych między filtrami źródło: java.sun.com Front Controller Front Controller • Problem: scentralizowany punkt obsługi wszystkich żądań w warstwie prezentacji • Siły – Wspólna logika sterująca dla wielu żądań – Oddzielenie logiki od widoku – Centralizacja i kontrola punktów dostępu • Rozwiązanie – Serwlet, JSP, ActionServlet, DispatcherServlet • Konsekwencje – Poprawa zarządzania i oddzielenie ról źródło: java.sun.com Service Locator Service Locator • Problem: proste wyszukiwanie usług i komponentów biznesowych • Siły – Centralizacja wyszukiwania usług i komponentów – Wykorzystanie interfejsu JNDI • Rozwiązanie – Klasa Java • Konsekwencje – Prosty i jednolity dostęp do komponentów i usług – Poprawa wydajności komunikacji sieciowej źródło: www.corej2eepatterns.com Session Façade Session Façade • Problem: udostępnienie komponentów i usług biznesowych zdalnym klientom • Siły – Brak zależności między klientem i warstwą biznesową – Centralizacja logiki biznesowej – Ukrycie zależności w warstwie biznesowej • Rozwiązanie – Sesyjny komponent EJB • Konsekwencje – Poprawa wszystkich aspektów aplikacji źródło: www.corej2eepatterns.com Data Access Object Data Access Object • Problem: ukrycie logiki dostępu do danych • Siły – Oddzielenie warstwy danych od reszty aplikacji – Jednolity interfejs do różnych źródeł danych • Rozwiązanie – Klasa Java • Konsekwencje – Ukrycie schematów danych – Hermetyzacja dostępu do danych w postaci osobnej warstwy źródło: www.corej2eepatterns.com Materiały dodatkowe • "Core J2EE Wzorce projektowe", D.Alur, J.Crupi, D.Malks, ISBN 83-7361-344-7, Helion 2004 • Sun Developer Network, http://sun.java.com/blueprints/patterns • Core J2EE Patterns, http://www.corej2eepatterns.com
