Service layer - classi di servizio grassi?

Question

Service layer - classi di servizio grassi?

#1 da (2 voti)
#2 da (2 voti)

2

Diciamo che ho un servizio per Job Offer entità nell'app CRM. L'offerta di lavoro è correlata a molte molte cose, quindi ci saranno molti metodi sul livello di servizio per interagire con sopra.

Quale dovrebbe essere considerato un approccio migliore: una grande classe di servizio per tutta la famiglia Job Offer (come 50 metodi in servizio) o la suddivisione in pochi servizi più piccoli destinati a parti specifiche delle interazioni (una per il salvataggio / l'aggiornamento dati di base, uno per la gestione dei dettagli dell'offerta di lavoro, uno per le domande di lavoro ecc.)

I professionisti di una classe di grassi che vedo è che potrebbe essere più ASCIUTTO di più servizi più piccoli. Ovviamente si può sempre chiamare un altro servizio da un altro servizio, ma ciò causerà meno modularità. Contro - Temo che una classe di servizi di grandi dimensioni sarà più difficile da mantenere e da testare.

architecture design-patterns enterprise-architecture

posta ex3v 09.01.2015 - 09:25

fonte

2 risposte

Leggi altre domande sui tag architecture design-patterns enterprise-architecture

Viste strongmente tipizzate, ViewModel e MVC Come implementare il pattern di repository per un'app che cambierà il suo database da sql a nosql in un paio d'anni?

score 2 · Answer 1

Beh, di solito sono contro qualcosa di grasso nell'applicazione, a meno che non ci sia modo di evitarlo. Quindi, io dico: rompere a parte.

Leggendo il tuo commento, posso suggerire alcune idee:

I'm talking about methods like

"saveOffer", "deleteOffer", "activateOffer" - OfferService sicuramente.
"markAllApplicationsAs" - non sono sicuro di questo. Probabilmente appartiene solo a OfferApplicationService con appena offertaId passato come filtro
"getOfferApplications" - OfferApplicationService con offerId passato come filtro che dico.

and so on. I thought that those methods should belong to service layer.

Certo, dovrebbero.

score 2 · Answer 2

L'altra estremità dello spettro dalla classe del servizio grasso è l'uso di comandi e un processore di comandi. Fondamentalmente ognuno dei tuoi metodi di servizio è suddiviso in un proprio comando.

Questo articolo di Ian Cooper fornisce una buona descrizione del refactoring da un fat service ai comandi:

Perché usare il comando pattern del processore nel livello di servizio

Alcuni professionisti di questo sono le singole responsabilità incentrate sul rasoio delle tue classi e la testabilità migliorata che ciò comporta. Alcuni svantaggi: ora hai introdotto un livello aggiuntivo di riferimento indiretto che non è sempre facile da capire, e ottieni un'esplosione di classe.