Nell'accesso ai dati separato e nel livello della logica aziendale, posso utilizzare le classi del framework Entity nel livello aziendale?

Question

In accesso dati separato livello di business logic &, è possibile utilizzare le classi di framework Entity nel livello aziendale?

EDIT: Non credo che in futuro sarà necessario sostituire il livello di accesso ai dati dalla logica aziendale (ad esempio, sarà SQL Server), tuttavia lo farò per il livello dell'interfaccia utente. Quindi la domanda è più importante per essere ci sono dei problemi principali con l'utilizzo di classi EF per me nel livello aziendale? Sembra che ci sarebbe meno codice idraulico.

Answer 1

In genere, l'approccio "best practice" sarebbe qualcosa di simile:

• nel vostro strato di dati, si dispone di entità EF che vengono caricati da e memorizzati nel database

• in nel tuo livello aziendale, hai i tuoi oggetti dominio (solo classi C#) che rappresentano i dati su cui la tua app deve lavorare. Quelli possono essere più o meno identici a un'entità di livello dati, oppure possono contenere diverse entità "atomiche" per creare un oggetto di business, oppure possono essere molto diversi. Per alleggerire la necessità di molte istruzioni di assegnamento di mano destra e di sinistra (per spostare i valori delle proprietà avanti e indietro tra entità del livello dati e oggetti del livello aziendale), dovresti provare strumenti come AutoMapper che rendono davvero facile impostare up "mappature" tra tipi di oggetti simili e permettono di assegnare facilmente quei tipi avanti e indietro

• il tuo livello di interfaccia utente (s) sarà poi visualizzare e rappresentare oggetti strato di business per l'utente per informazioni e/o manipolazione

Il vantaggio è che il modello di dominio del livello aziendale rappresenta gli oggetti aziendali reali con i quali si sta lavorando e diventa più o meno indipendente dal modo in cui questi re veramente memorizzato nel livello dati. Inoltre, questo evita di "incollare" il tuo livello di interfaccia utente a una particolare tecnologia di accesso ai dati.

Naturalmente - che è la migliore pratica consigliata per un'applicazione su scala aziendale, in cui potrebbe essere necessario scambiare l'accesso ai dati strato ecc Per un'applicazione più semplice, si potrebbe ignorare quelle pratiche, sapendo quello che sei facendo e "bloccando" te stesso in EF se si utilizzano entità EF fino in alto attraverso il livello aziendale nell'interfaccia utente. Se ciò va bene per te e per lo scenario della tua app, non c'è motivo particolare per non farlo. Le entità EF sono classi di oggetti .NET perfettamente valide: derivano semplicemente da una classe di base comune (EntityObject anziché da object) e hanno una certa quantità di "bagaglio" che arriva. Ma non c'è niente che ti impedisca di utilizzare queste entità EF in tutta la tua app.

Answer 2

Come per tutte le domande di questa natura, la risposta dipende. Se si desidera una separazione chiara della logica di accesso ai dati e del livello aziendale, direi di no. Se questo è ciò a cui mirate, userei un modello di repository e IoC per costruire il livello di accesso ai dati, quindi potete scambiare un DAL stub per scopi di test unitari e quindi accedere al database quando si arriva al test funzionale.

Answer 3

Se è necessario essere in grado di modificare il modo in cui si accede al database senza dover riscrivere su molto codice, è meglio mantenere l'EF fuori dal livello aziendale. È possibile utilizzare l'Unità di lavoro e i modelli di repository per ottenere ciò; accedere a tutte le funzionalità del livello dati tramite interfacce. Se si rilascia EF, le interfacce rimangono invariate, è sufficiente modificare le classi di implementazione.

Tuttavia, esistono argomenti per non utilizzare UoW e repository, il principale è che DbContext fornisce già molte di queste funzionalità.

Ho avviato un progetto con un UoI e un repository sul livello dati e nessun riferimento EF al livello aziendale. Mentre progredivo sentivo che stavo solo lavorando per me stesso, e li ho lasciati. Invece, utilizzo l'accesso al contesto dal livello aziendale, eseguo qualsiasi conversione richiesta da DTO a livello aziendale POCO.

Nel mio scenario, sono fiducioso di restare con EF. Se non lo sei, considera quale approccio ti si addice.