Architektura aplikacji Java EE

Architektura aplikacji Java EE
DonVitoMarco
  • Rejestracja:ponad 12 lat
  • Ostatnio:7 miesięcy
  • Lokalizacja:Katowice
  • Postów:11
0

Mam pytanie odnośnie architektury aplikacji w Javie EE z użyciem komponentów EJB, zakładając, że mamy prosty serwis restowy, zaprojektowałem go mniej więcej tak:
diagram1

Po dłuższym zastanowieniu naszła mnie wątpliwość czy różne EJB powinny korzystać z różnych DAO czy komunikować między sobą:
diagram2

Szukając po internecie odpowiedzi znalazłem, że dużo ludzi preferuje jednak DAO zaimplementowane jako komponenty EJB:
diagram3

Diagramy są dużym uproszczeniem ale chodzi mi o ogólną ideę, która jest właściwa, albo, która jest lepsza?

vpiotr
  • Rejestracja:ponad 13 lat
  • Ostatnio:prawie 3 lata
1

Dao jako EJB to chyba overkill.
Będziesz chciał się do tych DAO dostawać z warstwy clienta / weba?

W razie niejasności polecam:

Zobacz pozostały 1 komentarz
vpiotr
@jarekr000000: chodzi o EJB... to w tym jest współczesnego?
jarekr000000
Z tego co kojarze to P o EEA to jest nawet książka z czasów EJB lizanego. (Tak do EJB2.1 i JavaEE 1.4). Sorry, ale już nawet JavaEE5 to całkiem inny sposób pisania.
vpiotr
Ja pracuje w ejb 2.1 ale jakos nie slyszalem o genialnych rozwiazaniach trojki. Chyba ze uwazasz adnotacje za cos odkrywczego. Niemniej jesli masz cos godnego polecenia dot. architektury i ejb 3.1 czy pozniejszego to napisz.
jarekr000000
Uważam adnotacje za kaszankę. Dramat. Ale EJB 2.1 z XMLem to dramat nawet większego kalibru. A co do polecania - to zależy co robisz/ co potrzebujesz. Ale generalnie nikomu i do niczego nie poleciłbym javaEE czy Springa. Są lepsze alternatywy. Web/Rest -> Ratpack. Messages/events / clustering -> Akka lub Vert.x. Prosty enterprise, microservisy -> Lagom.
vpiotr
Ale ja pytałem właśnie o EJB... :)
DonVitoMarco
  • Rejestracja:ponad 12 lat
  • Ostatnio:7 miesięcy
  • Lokalizacja:Katowice
  • Postów:11
0

Będziesz chciał się do tych DAO dostawać z warstwy clienta / weba?

Tylko i wyłącznie przez serwisy, nigdy bezpośrednio.

KA
KA
  • Rejestracja:prawie 12 lat
  • Ostatnio:prawie 5 lat
  • Lokalizacja:Warszawa
  • Postów:1683
0

Tylko nie EJB. Wystrzegaj się EJB.
A odnosnie robienia jakiś cudów na kiju tj. wydzielania dao jako osobne EJB czy cos w tym stylu to weź tak nie rob. Zrób to prosto.
Generalnie to co zaprezentowałeś jest okey tylko skasuj te EJB. Weź nie rób EJB, bo na prawde to jest mega słabe. I teraz prosto tak:

Ładujesz tam Spring Boota.
I masz serwisy i one normalnie , najnormalniej w świecie mają w sobie te DAO z którego korzystają. A konkretniej zamiast nazwy DAO co brzmi jak jakiś mnich chiński Tao Exo Pando to normalnie daj tam nazwe Repository. No i one najnormalniej w świecie w projekcie sobie wywołują te repozytoria. Wywołują normalnie tak jak się pisze w Javie. Nie przez refleksje, nie przez web sockety, nie przez http, nie przez osobne instancje EJB tylko normalnie wywołują. Jak projekt będzie bardziej skomplikowany to wtedy może coś będziesz musiał pomysleć. Ale ten level skomplikowania jest na razie poza twoim zasięgiem jak i moim. Normalnie ładujesz serwis a w niego dao. a nie jakies cuda na kiju dzikie węże. Tylko nie EJB bo jest stare i gowniane.


PROGRAMY NA ZAMÓWIENIE, ZALICZENIA STUDENCKIE, KONFIGURACJA SERWERÓW, SYSTEMÓW I BAZ DANYCH, STRONY INTERNETOWE, POMOC W PROGRAMOWANIU, POPRAWIENIE I OPTYMALIZACJA APLIKACJI
JAVA, C++, LINUX, WWW, SQL, PYTHON
POSIADAM KOMERCYJNE DOŚWIADCZENIE
TANIO, SZYBKO I PORZĄDNIE
Z KOMENTARZAMI OBJAŚNIAJĄCYMI KOD
PISZ NA PRYWATNĄ WIADOMOŚĆ
CENY JUŻ OD 49,99ZŁ ZA PROGRAM
ZAJMIJ SIĘ TYM CO CIĘ NAPRAWDĘ INTERESUJE!
caer
niech ktoś to usunie bo jeszcze ktoś uwierzy
YA
Siła argumentów zabija. Według mnie warto znać EJB, choćby przez to, żeby wiedzieć jak migrować aplikacje z EJB na inne technologie jak już będzie konieczność, bądź rozwijać istniejące ;-)
Cr0w
"tylko nie", "skasuj te", "weź nie rób" i pozamiatane ^^
S9
  • Rejestracja:ponad 10 lat
  • Ostatnio:6 miesięcy
  • Lokalizacja:Warszawa
  • Postów:3573
0

EJB to czyste zło. Korzystaj ze Springa. i do tego Springa Data JPA. Napiszesz o wiele mniej kodu do obslugi DAO Layer, a sam Spring jest o wiele bardziej logiczna, prostszą i testowalną platformą.


"w haśle <młody dynamiczny zespół> nie chodzi o to ile masz lat tylko jak często zmienia się skład"
AL
Deltaspike Data i tez mamy mniej kodu do obsługi DAO
DonVitoMarco
  • Rejestracja:ponad 12 lat
  • Ostatnio:7 miesięcy
  • Lokalizacja:Katowice
  • Postów:11
0

Korzystaj ze Springa. i do tego Springa Data JPA. Napiszesz o wiele mniej kodu do obslugi DAO Layer, a sam Spring jest o wiele bardziej logiczna, prostszą i testowalną platformą.

Znam i używałem i Spring Boot'a i Spring Data JPA i widzę wszelkie korzyści płynące z korzystania z nich.
Lecz zakładając, że chce pozostać przy zupełnie czystej Javie EE.

EJB to czyste zło.

Czy EJB w najnowszej wersji nie stało się trochę bardziej przyjemniejsze? Jedna adnotacja Stateless bez wymyślnych interfejsów local i remote, zapewnia na przykład transakcyjność itd.

S9
A dlaczego chcesz zostać przy czystej JEE?
S9
  • Rejestracja:ponad 10 lat
  • Ostatnio:6 miesięcy
  • Lokalizacja:Warszawa
  • Postów:3573
0

Tak, EJB może jest mniej ciężkie niż wcześniej, ale np w czystej JEE nie zrobisz testów integracyjnych z użyciem kontenera IoC


"w haśle <młody dynamiczny zespół> nie chodzi o to ile masz lat tylko jak często zmienia się skład"
DonVitoMarco
Trzymając się czystej Javy, do testów skorzystam z kontenera embedded OpenEJB
Shalom
No tak, bo CDI wcale nie jest częścią JEE :)
S9
@Shalom: no z tego co wiem nie ma odpowiednika MockMVC Springowego w JEE
DonVitoMarco
No to OpenEjb w testach przy starcie ładujący klasę proxy, która będzie symulować WebClienta na przykład z Apache Cxf i wywoływała odpowiednie endpointy restowe.
DonVitoMarco
  • Rejestracja:ponad 12 lat
  • Ostatnio:7 miesięcy
  • Lokalizacja:Katowice
  • Postów:11
0

Dlaczego czysta JavaEE, tak sobie postanowiłem dla swojego projektu, dla poćwiczenia, sprawdzenia kilku rozwiązań, może kolejny projekt zrobię sobie tylko na Springu.
Nie mówię, że JavaEE i Ejb jest super, ale też nie lubię stwierdzenia, że jest do d**y bo jest do d**y, dlatego nie używaj tego. Wolę stwierdzenia "użyj tego bo.. dzięki temu zyskasz to... ale nie będziesz miał tego..".
A zrobiła nam się mała wojenka spring vs javaee, a w sumie w poście chodziło o to, że to nie ma być aplikacja popierdułka napisana w jeden wieczór, dlatego zacząłem się zastanawiać jak ją zaprojektować i chciałem zasięgnąć rady, co da użycie takiej architektury, a co innej, czego nie dostrzegam. Bo zadziałać, zadziała w wszystkich 3 przypadkach, tylko działa, a "działa" to czasem kolosalna różnica. :)

SZ
  • Rejestracja:około 11 lat
  • Ostatnio:ponad 4 lata
  • Postów:616
1

W JEE robimy DAO jako EJB, bo przecież chcesz je wstrzykiwać i mieć tam propagacje transakcji i Entitymanagera

YA
  • Rejestracja:prawie 10 lat
  • Ostatnio:13 dni
  • Postów:2370
1
  1. Nie wiem jaki model zarządzania transakcjami przewidujesz. Czy nie łatwiej będzie zarządzać transakcjami jednak via EJB (opcja 3) ?
  2. Wprowadzasz zależność cykliczną między kopmonentami UserService<-->TeamService. Osobiście nie lubię takich zależności w projekcie. Może inni wskażą zalety takiego rozwiązania :)
  3. DAO jako EJB może być wykorzystane zdalnie + mniej zadumy nad obsługą transakcji.

-- Edited:
Do tego dochodzi aspekt bezpieczeństwa, opcja 3 pozwoli Ci łatwiej zarządzać uprawnieniami do wywoływania z "operacji dao".

edytowany 1x, ostatnio: yarel
DonVitoMarco
W pierwszym wypadku myślałem nad takim czymś: serwis będący ejb, czyli transakcyjny, metody z logiką w tym serwisie wykonuje operacje na bazie danych z klas dao, to wtedy nie potrzebowałbym dao jako ejb, bo chce mieć pewność, że moja metoda serwisowa wykona się od początku do końca? No faktycznie drugi pomysł nie jest dobry.
0

a po co serwisy i dao

jeden formularz

Kopiuj
<f:viewParam name="id" value="#{bakinBoon.mojaEncjaId}" />
<f:viewAction action="#{bakinBoon.loadModelData( bakinBoon.mojaEncjaId)}" />

x name:
#{bakinBoon.mojaEncjaX.name}

<form jsf:id="majform">
    <input type="text" jsf:id="title" jsf:value="#{bakinBoon.mojaEncjaZ.elo}" />
    <button type="submit" jsf:id="majbaton" jsf:action="#{bakinBoon.save( bakinBoon.mojaEncjaZ)}" >Save</button>
</form>

jeden bean

Kopiuj
@ViewScoped
@Stateful
class BakinBoon{
 
  @PersistenceContext EntityManager em;

  @Getter @Setter Long mojaEncjaId;

  //model
  @Getter MojaEncjaX mojaEncjaX;
  @Getter MojaEncjaZ mojaEncjaZ;

  @PostConstruct
  void konstraktor(){
        mojaEncjaZ = new mojaEncjaZ();
   }

  public void loadModelData( Long id ){
     mojaEncjaX = em.find( MojaEncjaX.class, id);
  }

  public String save( MojaEncjaZ mez){
      em.persist(mez);
      return "ok";
  }

}
DonVitoMarco
Tak jak napisałem schematy te które narysowałem, to jest tylko uproszczenie, aby pokazać meritum sprawy o którą mi chodzi, nie było sensu zaciemniać tego szkicu skomplikowaną logiką i setkami struktur.
jarekr000000
  • Rejestracja:ponad 8 lat
  • Ostatnio:około 23 godziny
  • Lokalizacja:U krasnoludów - pod górą
  • Postów:4708
0

Nie ma żadnej ważnej różnicy miedzy JavaEE i Springiem (klasycznym). To samo w innym worku. Tak samo ogłupiające.


jeden i pół terabajta powinno wystarczyć każdemu
KA
nie no bez przesady. jakas tam jest roznica

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.