Wzorce projektowe tworzą lepsze aplikacje J2EE

Od samego początku J2EE (Java 2 Platform, Enterprise Edition) upraszcza tworzenie aplikacji korporacyjnych w języku Java. Jednak w miarę rozpowszechniania J2EE programiści zdają sobie sprawę z potrzeby zdefiniowania podejść, które zarówno upraszczają, jak i standaryzują tworzenie aplikacji. Możesz zacząć osiągać ten cel, standaryzując warstwę architektoniczną aplikacji .

Warstwa architektoniczna generalnie hermetyzuje złożoność techniczną aplikacji niezależnie od logiki biznesowej, zapewniając w ten sposób luźne powiązanie między funkcjonalnością biznesową a podstawową infrastrukturą techniczną. W tym artykule wyjaśniam wyłaniającą się metodę budowania architektury aplikacji dla projektów J2EE - taką, która wykorzystuje wzorce projektowe, aby zapewnić standaryzację i prostotę wymaganą przez dobrą architekturę.

Architektura aplikacji i J2EE

J2EE to świetna technologia infrastruktury. Zapewnia jednolity standard dla zadań niższego poziomu stosu technologii, takich jak komunikacja z bazą danych lub dystrybucja aplikacji. J2EE nie prowadzi jednak programistów do tworzenia udanych aplikacji. Twórcy J2EE, patrząc w dół na stos technologii, zastanawiali się: „Jak możemy ustandaryzować te interfejsy API?” Powinni byli spojrzeć na twórców aplikacji i zapytać: „Jak mogę dać programistom elementy konstrukcyjne, których potrzebują, aby skupić się na swojej aplikacji biznesowej?”

Rozpoczynając nowy projekt J2EE, niektórzy członkowie zespołu często pytają: „Jeśli J2EE jest samą architekturą, dlaczego potrzebujemy więcej?” Wielu programistów utrzymywało to błędne przekonanie we wczesnych latach J2EE, ale doświadczeni programiści J2EE rozumieją, że J2EE nie zapewnia architektury aplikacji niezbędnej do konsekwentnego dostarczania wysokiej jakości aplikacji. Ci programiści często używają wzorców projektowych, aby wypełnić tę lukę.

Wzorce projektowe

W programowaniu wzorce projektowe pozwalają wykorzystać zbiorowe doświadczenia społeczności programistów, dzieląc się problemami i rozwiązaniami, które przynoszą korzyści wszystkim. Wzorzec projektowy musi uchwycić definicję problemu i kontekst, możliwe rozwiązanie i konsekwencje rozwiązania.

Na potrzeby architektury aplikacji J2EE wzorce projektowe dzielą się na dwie kategorie: ogólne wzorce tworzenia oprogramowania i wzorce, które identyfikują określone wyzwania J2EE. Wzorce projektowe specyficzne dla J2EE identyfikują minimalny zestaw znanych problemów, które powinna rozwiązać solidna architektura aplikacji. Pierwsza grupa, obejmująca wzorce tworzenia oprogramowania, które nie są specyficzne dla J2EE, okazuje się równie potężna - nie do identyfikowania problemów, ale do kierowania budową architektury.

Przyjrzyjmy się bardziej szczegółowo każdemu obszarowi.

Wzorce projektowe J2EE

Wzorce projektowe J2EE ewoluowały w ciągu ostatnich kilku lat, gdy społeczność Java zdobyła doświadczenie J2EE. Te wzorce projektowe identyfikują potencjalne problemy napotkane podczas korzystania z różnych technologii określonych przez J2EE i pomagają programistom w tworzeniu wymagań architektury aplikacji. Na przykład popularny wzorzec projektowy Front Controller przekształca nieustrukturyzowany kod serwletu w kontroler przypominający udoskonalony interfejs GUI (graficzny interfejs użytkownika).

Wzorce projektowe J2EE identyfikują te problemy domeny, które najprawdopodobniej pojawią się w projektach J2EE. Rzeczywiście, gdyby problemy były rzadkie, wzorce projektowe nie ewoluowałyby, aby im sprostać. Mając to na uwadze, odniesiesz korzyści z rozwiązania każdego problemu domeny w swojej architekturze. Aby rozwiązać je wszystkie, utwórz listę kontrolną w celu sprawdzenia poprawności architektury pod kątem kompletności. Ten proces kontrastuje z procesem dotyczącym wzorców projektowych tworzenia oprogramowania, które omówię dalej, ponieważ musisz stosować te wzorce tylko wtedy, gdy jest to stosowne.

Więc gdzie można znaleźć wzorce projektowe J2EE? Sun Microsystems oferuje dwie książki, które zawierają wiele wzorców J2EE:

  • J2EE BluePrint Group's Designing Enterprise Applications with the Java 2 Platform (Enterprise Edition), Nicholas Kassem et al. (Addison-Wesley, 2000; ISBN: 0201702770)
  • Podstawowe wzorce J2EE Sun Professional Services Group : najlepsze praktyki i strategie projektowania, Deepak Alur, John Crupi i Dan Malks (Prentice Hall, 2001; ISBN: 0130648841)

(Zobacz Zasoby, aby uzyskać linki do obu książek).

Poza zasobami firmy Sun, inne publikacje oferują informacje o wzorcach projektowych J2EE, w tym różne czasopisma branżowe lub strony internetowe Java (takie jak JavaWorld ), a także liczne książki. (Patrz Zasoby linki do niektórych z tych miejsc, w tym JavaWorld” s wzorców projektowych stronie Miejscowe Index).

Wzorce projektowe tworzenia oprogramowania

Należy również pamiętać o wzorcach projektowych tworzenia oprogramowania, podzielonych na ogólne wzorce projektowe zorientowane obiektowo (OO) i wzorce projektowe specyficzne dla języka Java. Na przykład wzorzec Factory reprezentuje potężny wzorzec projektowy OO do hermetyzacji tworzenia obiektów w celu umożliwienia ponownego użycia i spełnienia zmieniających się wymagań systemu. Ze swojej strony wzorce projektowe języka Java uwzględniają specyfikę języka Java. Niektóre są unikalne dla Javy i zwykle są nieformalne (na przykład wyjątki i prymitywy), podczas gdy inne są wzorcami obiektowymi udoskonalonymi do zastosowania w Javie. Słynna książka Gang of Four, Design Patterns autorstwa Erica Gammy i in., Szczegółowo opisuje liczne ogólne wzorce tworzenia oprogramowania, przydatne dla wszystkich programistów.

Nie odrzucaj tych wzorców tylko dlatego, że nie są one specyficzne dla J2EE. Wręcz przeciwnie, takie wzorce mogą okazać się równie potężne, jeśli nie bardziej, niż wzorce projektowe J2EE, ponieważ:

  • Podczas gdy wzorce projektowe J2EE są nowe i ewoluują (ponieważ J2EE jest nowe i ewoluuje), inne wzorce zyskują na wieku, ponieważ branża miała więcej czasu na ich przeglądanie i udoskonalanie.
  • Często służą jako podstawa, z której wywodzą się wzorce projektowe J2EE.
  • Tworzą fundament, na którym wdrażane są rozwiązania specyficzne dla J2EE. Prawidłowe skonstruowanie tego fundamentu w szerokim zakresie wpływa na solidność i rozciągliwość całej architektury. Jeśli fundament nie zostanie poprawnie zbudowany, zminimalizuje użyteczność architektury niezależnie od tego, ile problemów J2EE rozwiązuje.

Nie twórz listy kontrolnej obejmującej wzorce tworzenia oprogramowania, których wymaga Twoja architektura, tak jak w przypadku wzorców J2EE. Zamiast tego zastosuj takie wzorce tam, gdzie jest to właściwe, w oparciu o specyficzne wyzwania twojego projektu. Wielu programistów błędnie uważa, że ​​ich produkty poprawią się, jeśli będą używać więcej wzorców - lub jeśli używają ich wszystkich! Tak jednak nie jest. Decydując, które wzorce zastosować i jak używać ich razem, kieruj się dyskrecją i finezją.

Wzorce projektowe: gdzie jest kod?

Należy pamiętać, że wzorce projektowe nie są dostarczane z dokładną implementacją lub kodem źródłowym, którego będziesz używać. Oferta wzorców projektowych obejmuje zarówno rzadkie opisy tekstowe, jak i bogatą dokumentację, a nawet przykładowy kod. Wyzwanie polega na zastosowaniu potężnych pomysłów wzorców. Pomysły te należy zastosować w środowisku, w którym będą używane; środowisko definiuje poprawną implementację.

Jako analogię rozważ wzór projektowy do budowy fundamentu domu. Wzorzec projektowy identyfikuje problem, kontekst i możliwe rozwiązanie budowy fundamentu - informacje niezwykle cenne dla pracownika budowlanego w terenie. Jednak robotnik nadal musi zbudować fundament. Czy ten pracownik budowlany nie skorzystałby bardziej na uzyskaniu podstaw (podobnie jak programista otrzymałby implementację)? Może ta podstawa byłaby tylko płytą betonową, na której mógłby zostać zbudowany dom. Problem: Fundament musi być zintegrowany z samym domem i terenem, na którym będzie się znajdował. W jaki sposób taki prefabrykowany fundament może pomieścić wszystkie możliwe plany pięter domu (prostokąt, kwadrat i inne dziwne kształty) i wszystkie możliwe krajobrazy (na szczycie wzgórza,w środku lasu i tak dalej)?

W świecie oprogramowania możliwość korzystania z gotowych wzorców projektowych zależy od dwóch czynników:

  • Rozwiązaniem jest implementacja, a nie indywidualne wzorce projektowe. Rozwiązanie mogłoby obejmować wiele wzorców projektowych, a dzięki temu wiedziałoby, jak poszczególne wzorce projektowe współgrają ze sobą.
  • Rozwiązanie musi być adaptowalne, co odpowiada na ostatnie pytanie z analogii do gotowego fundamentu: fundament musi mieć możliwość dostosowania się do terenu i rzutów pięter. Jak możesz sobie wyobrazić, zbudowanie adaptowalnego fundamentu w przeciwieństwie do standardowego fundamentu wymagałoby niezwykle wykwalifikowanego rzemieślnika.

Typowe wzorce projektowe

W poniższej tabeli wymieniono niektóre typowe wzorce projektowe pochodzące zarówno ze źródeł J2EE, jak i szerszych wzorców obiektowych.

Typowe wzorce projektowe
Wzorce projektowe J2EE Wzorce rozwoju oprogramowania
Fasada sesji Singel
Asembler obiektów wartości Most
Wzorzec lokalizatora usług Prototyp
Delegat biznesowy Fabryka abstrakcyjna
Jednostka złożona Waga musza
Procedura obsługi listy wartości Mediator
Lokalizator usług Strategia
Jednostka złożona Dekorator
Obiekt wartości Stan
Usługa dla pracownika Iterator
Obiekt dostępu do danych Łańcuch odpowiedzialności
Filtr przechwytujący Kontroler widoku modelu II
Wyświetl pomocnika Memento
Widok złożony Budowniczy
Widok dyspozytora Metoda fabryczna

Przyjrzyjmy się dwóm przykładom wzorców projektowych J2EE: wzorcom Session Facade i Value Object. Oba pokazują, w jaki sposób wzorce projektowe J2EE koncentrują się na problemach specyficznych dla środowiska J2EE, w przeciwieństwie do wzorców projektowania oprogramowania, które ogólnie mają zastosowanie do wszelkich prac związanych z tworzeniem aplikacji.

Przykład: wzorzec J2EE fasady sesji

Wzorzec fasady sesji wyewoluował z doświadczeń z Enterprise JavaBeans (EJB). Systemy zbudowane na nowo wprowadzonych elementach EJB encji (które komunikują się z bazą danych) zwalniały do ​​przeszukiwania. Testy wydajności ujawniły problemy wynikające z wielu wywołań sieciowych wykonywanych podczas komunikacji z EJB jednostek, co zwiększyło obciążenie związane z ustanowieniem połączenia sieciowego, serializacją danych zarówno do wysyłania, jak i odbierania oraz inne efekty.

W odpowiedzi wzorzec Fasada sesji poprawił wydajność poprzez scentralizowanie tych wielu trafień w sieci w jedno połączenie. Session Facade wykorzystuje bezstanowy sesyjny EJB do pośredniczenia między wywołaniem klienta a wymaganą interakcją EJB jednostki. Istnieje więcej wzorców poprawiających wydajność dostępu do bazy danych, w tym wzorce Fast Lane Reader i Data Access Object.

Przykład: wzorzec J2EE Value Object

Wzorzec Value Object J2EE ma również na celu poprawę wydajności systemów korzystających z EJB w sieci. Te wywołujące obciążenie wywołania sieciowe z poprzedniego przykładu pobierają poszczególne pola danych. Na przykład, możesz mieć PersonEJB jednostkę z metod, takich jak getFirstName(), getMiddleName()i getLastName(). Dzięki wzorcowi projektowemu Value Object można zredukować takie wielokrotne wywołania sieciowe do jednego wywołania za pomocą metody w jednostce EJB, takiej jak getPersonValueObject(), która zwraca wszystkie dane naraz. Ten obiekt wartości zawiera dane, które reprezentuje jednostka EJB i można uzyskać do nich dostęp w razie potrzeby bez ponoszenia narzutu połączenia sieciowego.

Przykład: wzór Flyweight OO

Jako przykład szeroko stosowanego wzorca projektowego OO, rozważ wzorzec Flyweight, który poprawia wydajność aplikacji poprzez ponowne wykorzystanie obiektów. Oprogramowanie OO generuje narzut - zmarnowane cykle procesora, usuwanie elementów bezużytecznych i alokację pamięci - podczas tworzenia i niszczenia obiektu. Gdyby system mógł ponownie wykorzystać te obiekty, można by uniknąć tego narzutu. Obiekty te często nie nadają się jednak do ponownego użycia, ponieważ zawierają informacje (zwane stanem ) specyficzne dla bieżącego użytkownika obiektu. Wzorzec Flyweight umożliwia przeniesienie tego stanu w inne miejsce, dzięki czemu reszta obiektu może zostać ponownie wykorzystana.

Połącz je wszystkie razem: przykład wytrwałości

Teraz, gdy znasz już podstawy, możesz zacząć stosować wzorce projektowe w swoich praktykach programistycznych. Ale jak właściwie używasz wzorców? Zacznij od zidentyfikowania domeny lub problemu technicznego wymagającego rozwiązania. Trwałość - rozwiązanie odwiecznej niezgodności między obiektami a relacyjną bazą danych - stanowi dobry przykład dla większości aplikacji korporacyjnych. Zobaczmy kroki wymagane do zaprojektowania i zbudowania warstwy trwałości architektury aplikacji.

Postępując zgodnie z tradycyjną architekturą obiektową i podejściem do projektowania, utwórz przypadki użycia opisujące Twoje potrzeby w zakresie trwałości. Możliwe przypadki użycia obejmują:

  1. Trwałość obiektów powinna być przezroczysta z punktu widzenia programistów.
  2. Mechanizmy trwałości - EJB encji, obiekty dostępu do danych itd. - powinny być konfigurowalne na poziomie architektury.
  3. Nasza architektura powinna wykorzystywać technologie J2EE, ale hermetyzować zależności J2EE. Powinniśmy być w stanie zmienić dostawców serwerów aplikacji J2EE, wersje J2EE lub całkowicie zastąpić J2EE bez konieczności gruntownego przeglądu aplikacji.
  4. Wynikowa warstwa trwałości powinna nadawać się do ponownego wykorzystania w różnych projektach. Powinno to być częścią naszej bieżącej architektury aplikacji.

Po zidentyfikowaniu problemu możesz zdecydować, które wzorce mają zastosowanie. Pamiętaj, że w przypadku wzorców J2EE należy określić, które wzorce mają zastosowanie w obszarze problemu i się nimi zająć. Aby zachować trwałość, odpowiednie wzorce projektowe J2EE to (patrz podręczniki wzorców projektowych J2EE firmy Sun w sekcji Zasoby):

  • Obiekt wartości
  • Fast Lane Reader
  • Obiekt dostępu do danych
  • Fasada sesji
  • Jednostka złożona
  • Procedura obsługi listy wartości

Ponieważ będziesz zatrudniać EJB, uwzględnij wzorce delegata biznesowego i lokalizatora usług, aby uwzględnić dostęp do EJB.

Dodatkowo, rozwiązanie drugiego i trzeciego przypadku użycia wymaga tradycyjnych wzorców projektowania oprogramowania. Jak hermetyzować zależności i mieć konfigurowalne mechanizmy trwałości? Niektóre odpowiednie wzorce tworzenia oprogramowania obejmują:

  • Fabryka
  • Mediator
  • Strategia