Ho cercato alcune implementazioni dell'interazione Service Layer e Controller nei blog e in alcuni progetti open source. Tutti sembrano riferirsi a DbContext oggetto nelle classi di repository ma evitato di utilizzarli nelle classi di servizio. Classi di servizio che utilizzano essenzialmente riferimenti IQueryable<T> di DbSet<T> . Voglio sapere perché questa pratica è buona e perché DbContext non dovrebbe avere un riferimento in Service Layer.
NOTA: Sto scrivendo questa risposta come si applicherebbe a una domanda di Programmers.SE.
Gran parte del design delle applicazioni è astrazione , ad esempio nascondendo i dettagli di livello inferiore e fornendo un'interfaccia concettuale semplice ai consumatori. Un principio correlato è l'incapsulamento - i dettagli interni di un'operazione dovrebbero rimanere all'interno del componente e non dovrebbero trapelare nel mondo esterno.
In genere, vorremmo avere tutto il codice relativo al DB in un'unica posizione. Quindi creiamo un livello dedicato per esso e incapsuliamo tutta la logica DB in quel livello. Per quanto riguarda il livello di servizio, non sa nulla su come vengono recuperati i dati. Richiede solo alcuni dati dal livello dati, li ottiene "magicamente" e su di essi esegue la logica aziendale.
Questo rende molto facile cambiare la logica del DB. Ad esempio, lo scambio del database sottostante con uno equivalente ha un impatto trascurabile su altre aree dell'applicazione. Poiché il servizio non sa nulla del DB, finché ottiene gli stessi dati, continuerà a funzionare esattamente come prima.
Si noti che questo vale anche per altri livelli. Il livello dell'interfaccia utente non conosce la logica aziendale. Parla in termini di astrazioni a livello di dominio e le mostra al consumatore. In che modo questi oggetti del dominio sono generati e manipolati è il lavoro del livello aziendale e nascosto al suo interno.
Leggi altre domande sui tag c# entity-framework