Service Layers and Depositories

Question

Ho utilizzato i framework MVC per un po 'di tempo e mi piace molto come le preoccupazioni siano separate. Ho avuto la brutta abitudine di lasciare che i controller facciano un bel po 'di lavoro. Quindi sto davvero cercando un consiglio.

Quando ho iniziato a utilizzare MVC, ho avuto spesso il controllo del controller sui modelli dopo che il database era stato eseguito. Sapevo che era brutto, quindi mi sono trasferito nei modelli. Comunque non sono contento di questo perché voglio che i miei modelli siano molto utili.

Ho letto un po 'di lettura e vedo che le persone mantengono i loro controller e modelli snelli avendo un livello di servizio, che mi piace molto.

Sto solo cercando di capire come un livello di servizio e un repository dovrebbero lavorare tutti insieme. Ecco le mie ipotesi, puoi per favore farmi sapere se questo è un buon modo di lavorare?

1. Il controller può chiamare il repository direttamente se nessuna manipolazione deve essere fatto sui dati e come tale un livello di servizio non ha bisogno di essere coinvolti
2. Una volta che ogni lavoro deve essere fatto per i dati (logica di business) questo dovrebbe essere fatto nel livello di servizio e il controller effettuerà una semplice chiamata al livello di servizio come e quando richiesto
3. Una volta che il servizio ha fatto la sua logica di business, utilizzerà il repository come necessario (se i dati devono essere persistito).
4. I modelli dovrebbero idealmente essere mantenuti magri, idealmente come nient'altro che DTO
5. La convalida dei dati verrà eseguita all'interno dei modelli (utilizzando gli attributi di convalida MonoRail). Apprezzo che nemmeno uno gradisca inquinare i loro modelli con molti attributi, ma questa è una discussione diversa. Mi piace il beneficio degli attributi di convalida di MonoRail per la convalida automatica di jQuery nell'interfaccia utente.

Sto cercando di trasformare tutto il mio codice in un unico principio di responsabilità, quindi cercando di risolvere le mie pratiche di codifica.

Grazie

Answer 1

In primo luogo, non esiste un insieme di regole che sta andando a lavorare in ogni situazione. Il modo in cui modelli la tua applicazione dipende molto dal tipo e dalla complessità del progetto. Detto questo, ecco alcune idee:

1. Niente di male nel chiamare il repository da un controller. Assicurati solo che il controller non contenga logica aziendale.
2. Il servizio si occupa di (alcune) logica aziendale e utilizza altri servizi per farlo. Il repository è un tipo di servizio, non c'è niente di sbagliato nel chiamarlo da un servizio.
3. Il modello deve contenere la logica aziendale, in realtà si dovrebbe sempre provare a inserirlo prima nel modello. Se sono necessari dati esterni per eseguire tale logica aziendale (da un altro modello o dal repository), è necessario creare un servizio.
4. Niente di sbagliato con la convalida nei modelli. Usare gli attributi o meno è una questione di gusti (se ti piace, allora è buono). Spostare la convalida al di fuori del modello se diventa troppo complessa (creare un set esterno di regole).

Più importante, fare ciò che sembra giusto (di solito è la risposta giusta).

Answer 2

Ian Cooper ha appena scritto un post sul blog chiamato The Fat Controller proprio su questo argomento.

Answer 3

This video offre informazioni dettagliate su come organizzare la soluzione asp.net MVC e affrontare la separazione delle preoccupazioni e una migliore testabilità. Spero che aiuterà anche qualcun altro. Ho imparato alcune cose buone da esso.