Qual è lo scopo della logica aziendale che dovrebbe essere inserito in un bean di sessione stateless?

1

Sto cercando di capire come dimensionare la logica di business inserita nei bean di sessione stateless. È importante avere poca esperienza in questo argomento.

Nel caso che ho ora, esiste un'applicazione JEE in cui un servizio REST (JAX-RS) è responsabile della fornitura di dati a sistemi esterni. Nell'applicazione la logica aziendale è costituita da quanto segue:

  • acquisizione dei dati dal database tramite bean di sessione stateless
  • acquisizione di dati da altre fonti, in genere da altri servizi tramite un client REST
  • unione delle strutture dati nella forma desiderata
  • mappatura della struttura alle classi DTO che si adattano a un contratto

Secondo il mio piano, ci sarà un'applicazione responsabile per il controllo dei passaggi della logica di business, ha iniettato @EJB, client REST e Mapper.

Nella mia mente, @EJB è responsabile solo della comunicazione con il database, come repository. Ho la sensazione che i bean Session siano progettati più come rappresentanti della logica aziendale, compresa tutta la logica che ho descritto sopra.

Se lascio che i bean di sessione siano più grassi, la libreria delle applicazioni non è necessaria, quindi la mia intera applicazione è più leggera, meno complessa. L'unica domanda è la testabilità, che deve essere esaminata.

Quindi, la mia domanda è: qual è la dimensione sana di un bean di sessione? Tutta la logica aziendale può essere inserita nei bean di sessione? C'è una linea guida da seguire?

    
posta SayusiAndo 13.06.2017 - 10:30
fonte

0 risposte

Leggi altre domande sui tag