Livello di servizio e controller: chi si occupa di cosa?

In class stiamo imparando come creare un’applicazione Spring, anche se la spring non è direttamente coinvolta, abbiamo imparato come creare le interfacce per gli oggetti DAO e del livello di servizio.

Per favore correggimi se ho torto: il livello DAO è piuttosto astratto: contiene solo le operazioni CRUD ed è ulteriormente utilizzato per leggere i dati. (Es .: ottieni tutti gli oggetti, ottieni oggetti specifici, ecc.)

Livello di servizio: contiene servizi per creare cose ed eliminare cose, questo è dove dovrebbe essere la logica di business.

Ora tutto ciò ha senso nel livello di servizio; tranne gli oggetti “aggiornanti”. Metti solo una funzione di “aggiornamento” che salva l’object nel tuo database? O hai bisogno di definire la logica anche lì? È qui che la mia confusione è così, la mia comprensione è che gli oggetti in spring sono solo POJO. Ora chi convalida i dati?

Diciamo che ho un object “figlio” che ha: Name , SurName , Gender , Photo , Campi Birthdate . come chiamerei i servizi? O lasceresti semplicemente che il controller si occupasse della convalida, il che non mi sembra giusto. D’altra parte non sembra giusto debind ogni setter che deve essere chiamato al livello di servizio.

Quindi, fondamentalmente: aiutami a definire come salvare i tuoi oggetti tramite il livello di servizio.

Se si desidera che i controllori siano in grado di mantenere le modifiche a un object Child , tradizionalmente si avrà un metodo nel servizio denominato qualcosa come ChildService.update(Child newchild) , che gestirà la chiamata ai DAO corretti per mantenere la nuova versione di questo bambino.

I controllori sono liberi di chiedere il servizio a un bambino, cambiare i campi intorno (presumibilmente in base a qualche input dell’utente) – un design sano avrebbe il controller fare un po ‘di lavoro con il POJO figlio e quindi chiedere al servizio di mantenere la modifica. Il modello POJO non dovrebbe sapere nulla di un controller, servizio o DAO, ma semplicemente conserva i dati come suggerito: certamente non vorrebbe che ogni chiamata a setName() o setGender() comporti automaticamente un aggiornamento del database.

Invece, il controller e / o il servizio dovrebbero acquisire un object Child , fare tutto il lavoro necessario all’object nella sua unità di lavoro e quindi chiedere a un servizio (e quindi al DAO) di mantenere le modifiche.

La convalida può avvenire in più livelli: il controllore potrebbe voler convalidare qualsiasi input dell’utente web e il servizio potrebbe voler verificare che abbia un object Child valido prima che lo mantenga. Ha particolarmente senso avere un certo livello di convalida in entrambi i livelli nel caso in cui si voglia riutilizzare questo Servizio in altre capacità, come esporre un’interfaccia REST, un front-end diverso, ecc.

Generalmente un servizio di spring è transazionale. Le cose vanno in un particolare metodo di servizio perché dovrebbero essere raggruppate insieme nella stessa transazione. Se si desidera recuperare un object dal database, modificarlo e salvare la nuova versione, il recupero e il salvataggio devono essere nello stesso metodo di servizio. Quindi i tuoi metodi di servizio sono determinati in base a ciò che ti serve che l’applicazione faccia per l’utente.

Cerco di limitare i controller a svolgere attività relative alla convalida dei parametri http, decidere quale metodo di servizio chiamare con quali parametri, cosa inserire nella httpsession o richiesta, quale vista redirect o inoltrare a, o roba simile relativa al Web.

Per quanto riguarda la convalida: la convalida dei parametri di input nel controller è una buona cosa per assicurarsi che nessuno possa violare la vostra applicazione con input falsi. La convalida del controller tende a garantire che gli input siano sintatticamente giusti (incluso il rilevamento degli attacchi di iniezione) mentre la convalida del livello di servizio riguarda l’accertamento che lo stato delle cose nel database sia quello che si aspetta che sia.

Quindi i controller contengono il codice dell’infrastruttura web-framework, i servizi contengono il codice logico dell’applicazione.