Udostępnijmy architektury aplikacji internetowych opartych na Javie!

Istnieje wiele różnych architektur aplikacji internetowych, które mają być implementowane przy użyciu języka Java. Odpowiedzi na to pytanie mogą służyć jako biblioteka różnych projektów aplikacji internetowych z ich zaletami i wadami. Chociaż zdaję sobie sprawę, że odpowiedzi będą subiektywne, starajmy się być tak obiektywni, jak tylko potrafimy, i motywować wymienione przez nas za i przeciw.

Użyj poziomu szczegółowości, który preferujesz do opisu swojej architektury. Aby Twoja odpowiedź miała jakąkolwiek wartość, musisz przynajmniej opisać główne technologie i pomysły użyte w opisywanej architekturze. I wreszcie, kiedy powinniśmy wykorzystać Twoją architekturę?

Zacznę...

Przegląd architektury

Korzystamy z 3-warstwowej architektury opartej na otwartych standardach firmy Sun, takich jak Java EE, Java Persistence API, Servlet i Java Server Pages.

• Trwałość
• Biznes
• Prezentacja

Możliwe przepływy komunikacyjne między warstwami są reprezentowane przez:

Persistence <-> Business <-> Presentation

Co na przykład oznacza, że ​​warstwa prezentacji nigdy nie wywołuje ani nie wykonuje operacji utrwalania, zawsze robi to przez warstwę biznesową. Ta architektura ma spełniać wymagania aplikacji internetowych o wysokiej dostępności.

Trwałość

Wykonuje operacje tworzenia, odczytu, aktualizacji i usuwania ( CRUD ). W naszym przypadku używamy ( Java Persistence API ) JPA i obecnie używamy Hibernate jako naszego dostawcy trwałości i używamy jego EntityManager .

Ta warstwa jest podzielona na wiele klas, z których każda zajmuje się określonym typem jednostek (tj. Jednostki związane z koszykiem mogą być obsługiwane przez jedną klasę trwałości) i jest używana przez jednego i tylko jednego menedżera .

Ponadto warstwa ta przechowuje również podmioty WZP , które są takie rzeczy jak Account, ShoppingCartetc.

Biznes

Cała logika związana z funkcjonalnością aplikacji internetowej znajduje się w tej warstwie. Funkcją tą może być zainicjowanie przelewu pieniężnego dla klienta, który chce zapłacić za produkt on-line przy użyciu swojej karty kredytowej. Równie dobrze może to być utworzenie nowego użytkownika, usunięcie użytkownika lub obliczenie wyniku bitwy w grze internetowej.

Ta warstwa jest podzielona na wiele klas, a każda z tych klas jest oznaczona, @Statelessaby stać się bezstanowym komponentem Session Bean (SLSB). Każdy SLSB jest nazywany menedżerem i na przykład menedżer może być klasą z adnotacjami, jak wspomniano AccountManager.

Kiedy AccountManagermusi wykonać operacje CRUD, wykonuje odpowiednie wywołania wystąpienia AccountManagerPersistence, które jest klasą w warstwie trwałości. Z grubsza można przedstawić dwie metody AccountManager:

...
public void makeExpiredAccountsInactive() {
    AccountManagerPersistence amp = new AccountManagerPersistence(...)
    // Calls persistence layer
    List<Account> expiredAccounts = amp.getAllExpiredAccounts();
    for(Account account : expiredAccounts) {
        this.makeAccountInactive(account)
    }
}
public void makeAccountInactive(Account account) {
    AccountManagerPersistence amp = new AccountManagerPersistence(...)
    account.deactivate();
    amp.storeUpdatedAccount(account); // Calls persistence layer
}

Używamy transakcji menedżera kontenerów, więc nie musimy samodzielnie rozgraniczać transakcji. Zasadniczo dzieje się to pod maską, gdy rozpoczynamy transakcję podczas wprowadzania metody SLSB i zatwierdzamy ją (lub wycofujemy) bezpośrednio przed wyjściem z metody. Jest to przykład konwencji zamiast konfiguracji, ale nie potrzebowaliśmy jeszcze niczego poza domyślną wymaganą.

Oto jak samouczek Java EE 5 firmy Sun wyjaśnia atrybut Wymaganej transakcji dla komponentów Enterprise JavaBeans (EJB):

Jeśli klient działa w ramach transakcji i wywołuje metodę komponentu bean przedsiębiorstwa, metoda jest wykonywana w ramach transakcji klienta. Jeśli klient nie jest powiązany z transakcją, kontener rozpoczyna nową transakcję przed uruchomieniem metody.

Atrybut Wymagany jest niejawnym atrybutem transakcji dla wszystkich metod komponentu bean przedsiębiorstwa działających z rozgraniczeniem transakcji zarządzanych przez kontener. Zwykle nie ustawia się atrybutu Wymagane, chyba że trzeba zastąpić inny atrybut transakcji. Ponieważ atrybuty transakcji są deklaratywne, można je później łatwo zmienić.

Prezentacja

Nasza warstwa prezentacji odpowiada za ... prezentację! Odpowiada za interfejs użytkownika i wyświetla informacje użytkownikowi, tworząc strony HTML i odbierając dane wejściowe użytkownika za pośrednictwem żądań GET i POST. Obecnie używamy kombinacji starego serwletu + Java Server Pages ( JSP ).

Warstwa wywołuje metody w menedżerach warstwy biznesowej w celu wykonania operacji żądanych przez użytkownika i otrzymania informacji do wyświetlenia na stronie internetowej. Czasami informacje otrzymane z warstwy biznesowej są mniej skomplikowanymi typami, jak te Stringi intinne, a innym razem jednostki JPA .

Plusy i minusy architektury

Plusy

• Posiadanie wszystkiego, co jest związane z określonym sposobem wykonywania trwałości w tej warstwie, oznacza tylko, że możemy zamienić używanie JPA na coś innego, bez konieczności ponownego pisania czegokolwiek w warstwie biznesowej.
• Łatwo nam zamienić naszą warstwę prezentacji na coś innego i prawdopodobnie tak się stanie, jeśli znajdziemy coś lepszego.
• Pozwolenie kontenerowi EJB na zarządzanie granicami transakcji jest przyjemne.
• Używanie Servlet + JPA jest łatwe (na początek), a technologie są szeroko stosowane i wdrażane na wielu serwerach.
• Korzystanie z Java EE ma nam ułatwić stworzenie systemu wysokiej dostępności z równoważeniem obciążenia i przełączaniem awaryjnym . Obydwoje uważamy, że musimy mieć.

Cons

• Korzystając z JPA, możesz przechowywać często używane zapytania jako nazwane zapytania, używając @NamedQueryadnotacji w klasie jednostki JPA. Jeśli masz jak najwięcej związanych z trwałością w klasach trwałości, tak jak w naszej architekturze, spowoduje to rozłożenie lokalizacji, w których możesz znaleźć zapytania, aby uwzględnić również encje JPA. Przegląd operacji trwałości będzie trudniejszy, a tym samym trudniejszy w utrzymaniu.
• Mamy jednostki JPA jako część naszej warstwy trwałości. Ale Accountczy ShoppingCartnie są to naprawdę obiekty biznesowe? Odbywa się to w ten sposób, że musisz dotknąć tych klas i przekształcić je w jednostki, z którymi JPA wie, jak sobie radzić.
• Encje JPA, które są również naszymi obiektami biznesowymi, są tworzone jako obiekty transferu danych ( DTO ), znane również jako obiekty wartości (VO). Powoduje to anemiczny model domeny, ponieważ obiekty biznesowe nie mają własnej logiki z wyjątkiem metod akcesorów. Cała logika jest wykonywana przez naszych menedżerów w warstwie biznesowej, co skutkuje bardziej proceduralnym stylem programowania. To nie jest dobry projekt obiektowy, ale może nie stanowi to problemu? (W końcu orientacja obiektowa nie jest jedynym paradygmatem programowania, który przyniósł rezultaty).
• Używanie EJB i Java EE wprowadza trochę złożoności. I nie możemy używać wyłącznie Tomcata (dodanie mikro-kontenera EJB nie jest wyłącznie Tomcat).
• Istnieje wiele problemów z używaniem Servleta + JPA. Skorzystaj z Google, aby uzyskać więcej informacji na temat tych problemów.
• Ponieważ transakcje są zamykane przy wychodzeniu z warstwy biznesowej, nie możemy załadować żadnych informacji z jednostek JPA, które są skonfigurowane do ładowania z bazy danych, gdy jest to potrzebne (przy użyciu fetch=FetchType.LAZY) z warstwy prezentacji. Spowoduje to wyjątek. Przed zwróceniem encji zawierającej tego typu pola musimy upewnić się, że wywołaliśmy odpowiednie metody pobierające. Inną opcją jest użycie Java Persistence Query Language ( JPQL ) i wykonanie FETCH JOIN. Jednak obie te opcje są nieco uciążliwe.

Ok, zrobię (krótszy) jeden:

• Frontend: Tapestry (3 dla starszych projektów, 5 dla nowszych projektów)
• Warstwa biznesowa: wiosna
• DAO: Ibatis
• Baza danych: Oracle

Korzystamy z obsługi transakcji Sping i rozpoczynamy transakcje po wejściu do warstwy usług, propagując w dół do wywołań DAO. Najwięcej wiedzy na temat modeli biznesowych ma warstwa usług, a DAO wykonują stosunkowo prostą pracę CRUD.

Niektóre bardziej skomplikowane kwestie związane z zapytaniami są obsługiwane przez bardziej skomplikowane zapytania w zapleczu ze względu na wydajność.

Zaletą używania Springa w naszym przypadku jest to, że możemy mieć instancje zależne od kraju / języka, które znajdują się za klasą Spring Proxy. W zależności od użytkownika w sesji, podczas wykonywania połączenia używana jest prawidłowa implementacja kraju / języka.

Zarządzanie transakcjami jest prawie przejrzyste, wycofywanie wyjątków w czasie wykonywania. W miarę możliwości używamy niezaznaczonych wyjątków. Kiedyś robiliśmy sprawdzone wyjątki, ale wraz z wprowadzeniem Spring widzę zalety niezaznaczonych wyjątków, obsługując je tylko wtedy, gdy jest to możliwe. Unika wielu szablonowych rzeczy typu „złap / wyrzuć” lub „wyrzuca”.

Przepraszamy, jest krótszy niż twój post, mam nadzieję, że uznasz to za interesujące ...

Idealne dziś technologie tworzenia sieci Web oparte na języku Java.

Warstwa internetowa:

HTML + CSS + Ajax + JQuery

RESTFul kontroler sieciowy / akcja / warstwa przetwarzania żądań:

Play Framework

Logika biznesowa / warstwa usług:

Używaj czystego kodu Java tak długo, jak to możliwe. Tutaj można dokonać fuzji usług internetowych.

Warstwa transformacji danych XML / JSon:

XMLTool (Search On Google Code), JSoup, Google GSon, XStream, JOOX (Search On Google Code)

Warstwa trwałości:

CRUD: JPA lub SienaProject lub QueryDSL / złożone zapytania: JOOQ, QueryDSL

Oto moje 5 centów

Prezentacja

Android, Angular.JS WebClient, OAUTHv2

API

REST, Jersey (JAX-RS), Jackson (de- / serializacja JSON), obiekty DTO (inne niż modele logiki biznesowej)

Logika biznesowa

Wiosna dla obsługi DI i zdarzeń. Podejście DDD do obiektów modelu. Dłuższe zadania są odciążane za pomocą SQS w modułach roboczych.

DAO

Model repozytorium z szablonami Spring JDBC do przechowywania jednostek. Redis (JEDIS) dla tablic wyników, używając uporządkowanych list. Pamięć Memcache dla Token Store.

Baza danych

MySQL, Memcached, Redis

W naszym projekcie kierujemy się:

Technologia front-end

• AngularJS
• HTML5
• css3
• Javascript
• Bootstrap 3

API

1. ODPOCZYNEK
2. JERSEY (JAX-RS)
3. PEWNOŚĆ ODPOCZYNKU
4. BUTY WIOSENNE
5. Jackson
6. bezpieczeństwo wiosenne

Logika biznesowa

• DANE WIOSENNE

• WIOSNA dane MongoDB

Baza danych

• MongoDB

Serwer (do buforowania)

• redis

Nadal używamy zwykłego stosu Struts-Spring-Hibernate.

W przypadku przyszłych aplikacji rozważamy Spring Web Flow + Spring MVC + Hibernate lub Spring + Hibernate + Web Services z interfejsem Flex.

Charakterystyczną cechą naszej architektury jest modularyzacja. Mamy wiele modułów, niektóre zaczynające się od 3 do maksymalnie 30 tabel w bazie danych. Większość modułów składa się z projektów biznesowych i internetowych. Projekt biznesowy zawiera logikę biznesową i trwałości, podczas gdy sieć WWW zawiera logikę prezentacji.
Na poziomie logicznym są trzy warstwy: biznes, trwałość i prezentacja.
Zależności:
Prezentacja zależy od Biznesu i Wytrwałości.
Wytrwałość zależy od Biznesu.
Biznes nie zależy od innych warstw.

Większość projektów biznesowych ma trzy typy interfejsów (uwaga: nie GUI, jest to programowa warstwa interfejsu Java).

1. Interfejs używany przez prezentację jako klient
2. Interfejs używany przez inne moduły, gdy są klientami modułu.
3. Interfejs, który można wykorzystać do celów administracyjnych modułu.

Często 1 rozszerza się na 2. W ten sposób łatwo jest zamienić jedną implementację modułu na inną. Pomaga nam to dostosować się do różnych klientów i łatwiej integrować. Niektórzy klienci kupią tylko określone moduły i musimy zintegrować funkcjonalność, którą już posiadają. Ponieważ warstwa interfejsu i implementacji są oddzielone, łatwo jest wdrożyć implementację modułu ad-hock dla tego konkretnego klienta bez wpływu na zależne moduły. Spring Framework ułatwia wprowadzanie różnych implementacji.

Nasza warstwa biznesowa oparta jest na POJO. Jedną z tendencji, którą obserwuję, jest to, że te POJO przypominają DTO. Cierpimy na anemiczny model domeny . Nie jestem do końca pewien, dlaczego tak się dzieje, ale może to wynikać z prostoty domeny problemowej wielu naszych modułów, większość pracy jest wykonywana w CRUD lub dlatego, że programiści wolą umieścić logikę w innym miejscu.

Oto jeszcze jedna architektura sieciowa, nad którą pracowałem:

Jednym z głównych wymagań było to, że aplikacja powinna obsługiwać telefony komórkowe / inne urządzenia. Aplikacja powinna być również rozszerzalna lub elastyczna w zależności od zmian w wyborze technologii.

Poziom prezentacji:

• JSP / JQuery (MVC po stronie klienta)
• Natywny Android
• Natywny iPhone

• Internet mobilny (HTML5 / CSS3 / Responsive design)

• Sprężynowe kontrolery REST (można zmienić na JAX-RS)

Poziom usług biznesowych:

Spring @Service (można zmienić na bezstanowy EJB)

Poziom dostępu do danych:

Wiosna @Repository (może zmienić się na bezstanowy EJB)

Poziom zasobów:

Jednostki hibernacji (JPA) (można zmienić na dowolny ORM)

Więcej informacji na temat książki podążającej za tą architekturą można znaleźć tutaj .

IMHO, większość z nas ma wspólny mianownik. Przynajmniej na zapleczu mamy jakąś formę kontenera IOC / DI i strukturę trwałości. Osobiście używam do tego Guice i Mybatis. Różnice dotyczą sposobu implementacji warstwy widoku / interfejsu użytkownika / prezentacji. Są tu 2 główne opcje (może być więcej) .. Na podstawie akcji (adresy URL mapowane na kontrolery) i opartej na komponentach. Obecnie używam warstwy prezentacji opartej na komponentach (przy użyciu furtki). Doskonale naśladuje środowisko pulpitu, w którym używam komponentów i zdarzeń w przeciwieństwie do adresów URL i kontrolerów. Obecnie szukam powodu, dla którego powinienem przejść na taką architekturę kontrolera URL (w ten sposób znalazłem się na tej stronie). Skąd ten szum wokół architektur RESTful i Stateless.

Aby odpowiedzieć w skrócie na to pytanie: piszę stanowe aplikacje internetowe przy użyciu struktury zorientowanej na komponenty na wierzchu kontenera Guice IOC i umieszczam dane w relacyjnej bazie danych za pomocą Mybatis.

Nieco inaczej i chciałbym twierdzić, że tutaj jest bardziej modularna architektura Java. Mamy:

1. Przedni koniec sprężyny WS / Rest / JSP
2. Spring MVC dla logiki usług biznesowych, zawierający logikę warstwy prezentacji oraz transakcje Spring
3. Interfejs komunikacyjny usług komponentowych, przeszukiwany przez EJB według usług biznesowych. EJB ustalają własne granice transakcji, które mogą łączyć transakcje Spring.
4. Implementacje usług komponentowych, znowu komponenty Spring
5. Warstwa integracji, MyBatis do integracji baz danych, Spring WS do integracji usług internetowych, inne technologie integracji dla innych usług
6. Komputery mainframe, bazy danych, inne usługi na innych serwerach ...

Oprócz powyższego mamy wspólne moduły bibliotek, które są wspólnym dostawcą funkcjonalności dla wszystkich usług.

Zastosowanie różnych warstw pozwala nam na pełne odsprzężenie i wymaganą modułowość. Jesteśmy również w stanie w pełni wykorzystać moc Java EE oraz Spring. Nic nie stoi na przeszkodzie, abyśmy na przykład użyli JSF jako interfejsu użytkownika w razie potrzeby.

W porównaniu z przykładową architekturą OP, myślę, że można to opisać jako cztery główne warstwy zamiast trzech, aczkolwiek z niespodzianką.

Pracowałem nad projektami, które wykorzystują ten sztywny wzorzec menedżera. Historycznie byłem wielkim zwolennikiem sztywnej hierarchii, w której wszystko mieści się w schludnym pudełku. W miarę postępów w mojej karierze w wielu przypadkach jest to wymuszone. Uważam, że przyjęcie bardziej zwinnego podejścia do projektowania aplikacji prowadzi do lepszego produktu. Co mam na myśli przez to stworzenie zestawu klas rozwiązujących dany problem. Zamiast mówić „Czy zbudowałeś menedżera do tego i tamtego?”

Bieżący projekt, nad którym pracuję, to aplikacja internetowa z połączeniem wywołań Spring MVC i RestEasy JSON / Ajax. Po stronie serwera osadzone w naszych kontrolerach jest rozsądna warstwa danych oparta na fasadzie z JPA / Hibernacją do bezpośredniego dostępu do bazy danych, niektórymi dostępami do EJB i niektórymi wywołaniami usług internetowych opartych na SOAP. Powiązanie tego wszystkiego razem to jakiś niestandardowy kod kontrolera Java, który określa, co serializować jako JSON i powrócić do klienta.

Nie spędzamy prawie czasu na próbach stworzenia jakiegoś ujednoliconego wzorca, zamiast tego decydując się na przyjęcie idei „Gorzej jest Lepiej” z Filozofii Projektowania Unix. Ponieważ znacznie lepiej jest pokolorować poza liniami i zbudować coś rozsądnego, szybko niż zbudować coś, co będzie zgodne z szeregiem ścisłych wymagań projektowych.

Komponenty w architekturze aplikacji sieci Web obejmują:

1: Przeglądarka: interakcja z klientem

        HTML
        JavaScript
        Stylesheet

2: Internet

3: serwer WWW

        CSS
        Image
        Pages(Java render )

4: Serwer aplikacji

        App Webapp (Java interaction)
        Others WebApps

5: Serwer bazy danych

        Oracle, SQL, MySQL

6: Dane