Differenza tra grails-app/services, grails-app/utils e cartelle src

Question

Sto cercando di capire qual è la differenza tra queste tre cartelle e cosa dovrei inserire in esse.

A partire da ora ho lanciato classi, interfacce e qualsiasi altra cosa direttamente correlata alla struttura delle mie classi di dominio (mediante estensione o implementazione) nella cartella src. Qualunque cosa implichi un'ulteriore logica transazionale oltre a quella che un controller Grails fa di default, ho inserito nella cartella grails-app/services. Infine, qualsiasi classe che contenga metodi "helper" (cioè confrontando varie cose, operazioni di stringa speciali, ecc.) Ho inserito nella cartella grails-app/utils.

Se mi è mancato il segno per ciò che queste cartelle dovrebbero essere utilizzate per favore mettimi sulla strada giusta.

Answer 1

Questo è molto vicino. grails-app/utils è per le classi Codec - è stranamente chiamato e sottodimensionato. Sposterei nuovamente le classi di supporto su src/groovy.

L'utilizzo dei servizi per eseguire il lavoro transazionale è ottimo, ma è possibile utilizzare anche i servizi per i metodi non transazionali. Aggiungi static transactional = false alle classi di servizio che dispongono di metodi di utilità che non richiedono transazioni. Si noti che non vi è alcuna transazionalità nei controller, quindi è necessario spostare tutta la persistenza in servizi transazionali.

I metodi di utilità statici in una classe helper src/groovy e i metodi non transazionali in un servizio sono praticamente equivalenti, quindi per me decidere quale percorso prendere dipenderebbe dalle dipendenze. Se la classe dipende dai bean Spring, crea un servizio e fai riferimento a loro tramite l'iniezione delle dipendenze. Altrimenti, rendilo semplicemente una classe di supporto.

Answer 2

Se vi trovate ad aggiungere un metodo a una classe di dominio che ha dipendenze da classi non di dominio, chiedetevi perché questo metodo potrebbe essere in un servizio. Questo porta ad avere un servizio corrispondente per quasi tutte le classi di dominio.

Ciò semplifica l'inserimento delle classi di dominio in un plug-in in modo da poter estendere le funzionalità creando diverse app utilizzando lo stesso modello di dominio anziché creare una grande palla di fango non gestibile. Essa è inoltre coerente con il modello di applicazione descritto da Zio Bob Martin negli anni perduti di Architettura http://www.youtube.com/watch?v=WpkDN78P884

Dato che si sta pensando di Architettura che sarebbe una buona idea di leggere una parte del lavoro di zio Bob e di Martin Fowler .