Entity Framework e separazione dei livelli


12

Sto cercando di lavorare un po 'con Entity Framework e ho una domanda sulla separazione dei livelli.

Di solito uso l'interfaccia utente -> BLL -> DAL e mi chiedo come usare EF qui.

Il mio DAL di solito sarebbe qualcosa di simile

GetPerson(id)
{
    // some sql
    return new Person(...)
}

BLL:

GetPerson(id)
{
    Return personDL.GetPerson(id)
}

UI:

Person p = personBL.GetPerson(id)

La mia domanda ora è: poiché EF crea il mio modello e DAL, è una buona idea avvolgere EF nel mio DAL o è solo una perdita di tempo?

Se non avessi bisogno di avvolgere EF, inserirò comunque Model.esmx nella sua libreria di classi o andrebbe bene inserirlo nel mio BLL e lavorarci un po '?

Non riesco davvero a vedere il motivo per avvolgere EF nel mio DAL, ma voglio sapere cosa stanno facendo gli altri.

Quindi, invece di avere quanto sopra, tralascerei il DAL e lo farei solo:

BLL:

GetPerson(id)
{
    using (TestEntities context = new TestEntities())
    {
            var result = from p in context.Persons.Where(p => p.Id = id)            
                    select p;
    }
}

Cosa fare?

Risposte:


13

L'esempio fornito è un'architettura a più livelli. So che è intenzionalmente semplificato, ma:

Il livello di presentazione è direttamente collegato all'entità Persona. Questo va bene solo nei casi più semplici, e sicuramente non quando stai cercando di definire i tuoi livelli.

Il metodo GetPerson utilizza anche una pratica piuttosto scorretta per la creazione di un nuovo contesto per ogni chiamata. Dovresti ottenere il contesto nel costruttore e sarà fornito dal tuo contenitore IOC.

Una struttura semplice ma efficace che ho usato è:

  • Project.Core: contiene modelli e interfacce di visualizzazione.
  • Project.DAL - con il mio EDMX e il codice generato.
  • Project.BLL - logica aziendale.
  • Project.Web: l'app Web stessa.

È importante notare che:

  • Il core non dipende da altre soluzioni.
  • DAL non dipende da nessuna altra soluzione.
  • Project.Web dipende da Core, ma non da DAL né da BLL.
  • BLL dipende da Core e DAL.

1
Il core sembrerebbe essere un livello di oggetto business.
sq33G

Questo è praticamente ciò che uso anche, tuttavia, aggiungerei DLL aggiuntive per soddisfare le dichiarazioni di interfaccia. In questo modo fai solo riferimento alle interfacce (e usi qualcosa come [url = unity.codeplex.com/[Unity[/url] per DI) e puoi essere sicuro che non ci sono dipendenze strane che hai indotto accidentalmente.
Ed James,

Normalmente, senza EF creo la mia classe Person in un livello "Model", quindi ho UI, BLL, DAL e Model dove: UI conosce BLL e Model. BLL conosce DAL e Model. DLL conosce il modello. Crea anche i tuoi "modelli di visualizzazione" e perché non usi semplicemente quelli che EF genera? (So ​​che questo va contro l'architettura a strati, ma quante volte in realtà si cambia il modo in cui si ottengono i dati?)
Thomas,

@Thomas che avvolge i modelli di vista in qualcosa di astratto renderà le unità di test molto più facili.
sq33G

3
modello! = visualizza modello
Boris Yankov il

2

Non è necessario avvolgere il tuo EDMX in nulla.

Se è possibile prevedere la possibilità di passare da EF a un altro approccio, è possibile estendere gli oggetti business (sfruttando le classi parziali) per implementare interfacce definite in un livello Business Object separato.

Quindi dal tuo codice ti occuperai solo di quelle interfacce e non delle classi generate in modo concreto. Potrebbe essere necessario un piccolo codice di colla per tenerlo insieme; che con EDMX può essere il tuo DAL.


Quindi se non prevedo alcuna modifica da EF a un altro approccio, il mio codice sopra sarebbe ok? Avrei quindi solo UI e BLL (dove si trova l'EDMX nel BLL)?
Thomas,

La mia risposta pragmatica sarebbe sì. Con l'avvertenza che potresti voler mettere l'EDMX nel suo piccolo assieme, se sarà grande e per lo più statico, in modo da non doverlo ricompilare / ridistribuire spesso.
sq33G

Ah, buon punto sulla ricompilazione / ridistribuzione :)
Thomas,

2

Esistono due approcci generali alla stratificazione: stratificazione rigorosa e stratificazione rilassata.

Un approccio rigorosamente stratificato limita i componenti di un livello ad interagire solo con i peer e con il livello direttamente sotto.

Un'applicazione a strati rilassati allenta i vincoli in modo che un componente possa interagire con i componenti da qualsiasi livello inferiore.

L'uso di livelli rilassati può migliorare l'efficienza perché il sistema non deve inoltrare chiamate semplici da un livello all'altro. D'altra parte, l'uso di strati rilassati non fornisce lo stesso livello di isolamento tra gli strati e rende più difficile scambiare uno strato inferiore senza influire sugli strati più alti.

Per soluzioni di grandi dimensioni che coinvolgono molti componenti software, è comune avere un gran numero di componenti allo stesso livello di astrazione che non sono coesivi. In questo caso, ogni strato può essere ulteriormente scomposto in uno o più sottosistemi coesivi. La Figura 2 illustra una possibile notazione UML (Unified Modeling Language) per rappresentare layer composti da più sottosistemi.

conclusione: se non ti serve lo strato intermedio, perdilo; non tutte le applicazioni richiedono lo stesso approccio e in qualche modo l'aggiunta di un livello solo a scopo di stratificazione avrà penalizzazioni sul costo della complessità e sulla manutenzione.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.