Architektura aplikacji Java EE

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:

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ą:

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

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

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

W razie niejasności polecam:

• https://martinfowler.com/books/eaa.html
• http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0471146153.html

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

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

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.

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ą.

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.

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

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. :)

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

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".

a po co serwisy i dao

jeden formularz

<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

@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";
  }

}

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