Ciao, È tutto da manuale. Casomai restituissi risultati sbagliati non è certo perché hai un solo oggetto, piuttosto perché c'è una gestione errata delle connessioni al database. Ma se usi spring sei tranquillo.
Dopodiché per codice stateless si intende oggetti che non mantengono uno stato. Più in generale bisogna scrivere codice rientrante. O almeno cosi mi insegnavano all'università. Il 16 feb 2018 8:01 PM, "Massimo Ugues [email protected] [it-torino-java-jug]" <[email protected]> ha scritto: Certo che va bene. Perché no? Il giorno ven 16 feb 2018 alle 16:17 Danilo Boi [email protected]<mailto:[email protected]> [it-torino-java-jug] <[email protected]<mailto:[email protected]>> ha scritto: Ok scusami , ma allora non va bene fare l'autowired di un oggetto repository in un service . Il Venerdì 16 Febbraio 2018 16:08, "Andrea Ligios [email protected]<mailto:[email protected]> [it-torino-java-jug]" <[email protected]<mailto:[email protected]>> ha scritto: Ciao, Stateless nel senso che essendo singleton non devono mantenere uno stato, non devono avere variabili. @Stateless è la notazione Java EE per definire un EJB stateless non-singleton, non è quello che stai cercando. 2018-02-16 14:41 GMT+01:00 Danilo Boi [email protected]<mailto:[email protected]> [it-torino-java-jug] <[email protected]<mailto:[email protected]>>: Ciao Massimo . Grazie della risposta . Mi preocupa perchè mi domando : Quando ho piu chiamate in contemporanea essendo oggetti Singhelton non rischio di restituire o eseguire operazioni su db Sbagliate ? una sorta di sovraposizione degli accessi a db. Per stateless intendi definire le mie cleassi services con @Stateless o anche i repository? Grazie mille ciao. Il Venerdì 16 Febbraio 2018 13:27, "Massimo Ugues [email protected]<mailto:[email protected]> [it-torino-java-jug]" <it-torino-java-jug@ yahoogroups.com<mailto:[email protected]>> ha scritto: Ciao. Direi che l'approccio e' da manuale, in spring per default tutti i bean hanno scopo singleton: la premessa importante da capire è che essendo singleton devono essere stateless. Perchè hai dei dubbi sul Repository? Direi che visto che possono essere visti come dei DAO anche loro dovrebbero essere stateless. Lo stereotipo @Repository mi pare che aggiunga degli aspetti per fare il translate delle sottostanti sql exceptions e ti permetta di iniettare un PersistenceContext o un EntityManager se dovessi averne bisogno (ripeto mi pare e su questo sto andando a braccio).. Secondo me quindi tutto corretto ;) P.S. I servizi Rest li stai annotando con @Controller? lo stereotipo dedicato è @RestController. 2018-02-16 11:12 GMT+01:00 Danilo Boi [email protected]<mailto:[email protected]> [it-torino-java-jug] <it-torino-java-jug@ yahoogroups.com<mailto:[email protected]>>: Ciao A tutti .. Grazie per aver accettato la richiesta. Mi sto occupando di programmazione java specificatamente , al momento , su Spring MVC. Sto sviluppando dei servizi Rest ....... In particolare la Parte ORM la sto gestendo con spring-mybatis Lasciando fare a spring la factory dei mapper Mentre per il layer di controllo sto seguendo l’approccio di alcuni esempi che ho trovato in rete e cioè Un oggetto controller annotato con @Controller Vari oggetti di servizio (Business logic) annotati come @Service Oggetti di manager dei mapper MyBatis annotati come @Repository All’interno di questo oggetto eseguo del @Controller eseguo @Autowired degli oggetti @Service Negli oggetti @Service eseguo @Autowired degli oggetti @Repository Che a loro volta iniettano i mapper MyBatis. Il dubbio che mi attanaglia da qualche giorno è che Spring All’avvio istanzia il @Controller con un riferimento a n @Service Questi a loro volta saranno “Singleton” che a loro volta iniettano Gli oggetti @Repository che a loro volta iniettano i mapper MyBatis. Da quello che ho capito mi trovo in una situazione in cui tutti gli oggetti sono “Singleton” e questo può andarmi bene per il @controller e forse anche per il @Service ma mi intimorisce per il layer @Repository. Ho sbagliato l’approccio ? Scusate e grazie . Ciao. -- Massimo Ugues -- Massimo Ugues
