Sto usando livello di servizio in modo corretto?

Question

Ho letto su DDD e penso che potrebbe essere l'utilizzo di servizi di sbagliato, o almeno in un modo non così ideale. Le mie classi di servizio tendono ad avere un bel paio di variabili di istanza contenenti riferimenti repository e sembrano fare un sacco di lavoro (cioè hanno un sacco di metodi).

E 'opportuno creare servizi più mirati? Come un metodo per ogni servizio che esegue una logica specifica? Inoltre, dovrebbero classi di servizio memorizzare variabili d'istanza ad altri soggetti? Ho letto qualcosa sui servizi apolide, non sono sicuro se mi sto rompendo la regola da avere quelle variabili di istanza.

Grazie!

Answer 1

  

Le mie classi di servizio tendono ad avere abbastanza   un paio di variabili di istanza ...

Questo non è necessariamente un codice-odore. Se il servizio richiede molte dipendenze per completare il suo lavoro, questo è semplicemente un dato di fatto.

  

... sembrano fare un sacco di lavoro (cioè   hanno un sacco di metodi).

     

E 'consigliabile creare servizi più mirati?

Come regola generale, il più granulare possibile rendere il vostro servizio-interfacce (cioè i meno metodi), il migliore (mai avuto alla pesca a strascico attraverso un'interfaccia con cinquanta metodi su di esso alla ricerca di quello che si desidera chiamare? ). Ma a meno che non si stanno rilasciando come un'API pubblica, la granularità del servizio interfacce può essere raffinato come si va avanti. Spesso, quando si inizia un progetto, comincerò con un solo servizio, e dividerlo nel tempo. Se sei il consumatore di questi servizi, poi, quando si inizia a sentire il dolore di un'interfaccia di arrivare a grandi dimensioni, si sa che è il momento di rompere in su. Naturalmente, se questo è un'API pubblica, allora si dovrà fare molto di design più up-front.

  

Inoltre, dovrebbero classi di servizio memorizzare variabili d'istanza ad altri soggetti? Ho letto qualcosa sui servizi apolide, non sono sicuro se mi sto rompendo la regola da avere quelle variabili di istanza.

Memorizzazione di dipendenze come variabili di istanza non implica necessariamente che il servizio non è senza stato, a patto che le variabili di istanza sono anche senza stato. Per essere considerato stateless, chiamate di metodo su un servizio non devono in alcun modo dipendono metodi precedenti hanno chiamato. Dovreste essere in grado di caricare una singola istanza del servizio, e lo hanno condiviso per la propria applicazione (vale a dire un'istanza di un servizio senza stato non dovrebbe essere specifico per la sessione di un particolare utente). In altre parole, il servizio non deve mantenere uno stato tra le chiamate di metodo. Memorizzazione di una dipendenza repository stateless come variabile su un'istanza di servizio non viola questo requisito.

Il motivo per servizi senza stato è un obiettivo auspicabile, sta avendo nessuno Stato riduce notevolmente la possibilità di errori. Semplifica la sperimentazione di un metodo di servizio limitando i provini casi variando i parametri passati, piuttosto che doversi preoccupare lo stato precedente del servizio. Si può anche offrire vantaggi prestazionali.

Answer 2

Mi raccomando di leggere su iniezione di dipendenza, l'inversione del controllo e simili.

Ecco l'articolo di Fowler: http://martinfowler.com/articles/injection.html , anche se ho sempre trovato ad essere un po 'sopra le righe. Vorrei provare a piedi attraverso un tutorial che indica di utilizzare un contenitore DI / CIO.