Architettonicamente parlando, un livello di astrazione del database, come l'Entity Framework di Microsoft, annulla la necessità di un Data Access Layer separato?

11

Il modo in cui era

Per anni ho organizzato le mie soluzioni software in questo modo:

  • Data Access Layer (DAL) per astrarre l'attività di accesso ai dati
  • Business Logic Layer (BLL) per applicare le regole aziendali ai set di dati, gestire l'autenticazione, ecc.
  • Utilità (Util) che è solo una libreria di metodi di utilità comuni che ho costruito nel tempo.
  • Presentation Layer che potrebbe ovviamente essere web, desktop, mobile, qualunque sia.

Il modo in cui è ora

Negli ultimi quattro anni ho utilizzato Microsoft Entity Framework (io sono prevalentemente uno sviluppatore .NET) e sto riscontrando che avere il DAL sta diventando più ingombrante che pulito a causa del fatto che Entity Framework ha già fatto il lavoro che il mio DAL ha usato per fare: astrae il business di eseguire CRUD contro un database.

Quindi, di solito finisco con un DAL che ha una collezione di metodi come questa:

public static IQueryable<SomeObject> GetObjects(){
    var db = new myDatabaseContext();
    return db.SomeObjectTable;
}

Quindi, nella BLL, questo metodo viene usato come tale:

public static List<SomeObject> GetMyObjects(int myId){
    return DAL.GetObjects.Where(ob => op.accountId == myId).ToList();
}

Questo è un semplice esempio, ovviamente, dato che la BLL di solito ha più linee logiche applicate, ma sembra un po 'eccessivo mantenere un DAL per un ambito così limitato.

Non sarebbe meglio abbandonare semplicemente il DAL e semplicemente scrivere i miei metodi BLL come tali:

public static List<SomeObject> GetMyObjects(int myId){
    var db = new myDatabaseContext();
    return db.SomeObjectTable.Where(ob => op.accountId == myId).ToList();
}

Sto pensando di abbandonare il DAL da progetti futuri per le ragioni sopra esposte ma, prima di farlo, volevo interrogare la comunità qui per il tuo giudizio retrospettivo / previdenza / opinioni prima di iniziare un progetto e scoprire un problema Non ho previsto.

Ogni pensiero è apprezzato.

Aggiornamento

Il consenso sembra essere che un DAL separato non è necessario ma (fare la mia inferenza qui) è una buona idea per evitare il blocco del fornitore. Ad esempio, se ho un DAL che sta astragendo le chiamate EF come illustrato sopra , se mai dovessi passare ad un altro fornitore, non ho bisogno di riscrivere il mio BLL. Solo le query di base nel DAL dovrebbero essere riscritte. Detto questo, trovo difficile immaginare uno scenario in cui ciò accada. Posso già creare un modello EF di un db Oracle, MSSQL è un dato, sono abbastanza sicuro che anche MySql sia possibile (??) quindi non sono sicuro che il codice aggiuntivo possa mai garantire un ROI utile.

    
posta Matt Cashatt 23.08.2013 - 15:25
fonte

3 risposte

6

Non sono sicuro se questa è la risposta che stai cercando .. ma qui va.

Lo facciamo per mantenere le cose separate / organizzate. Sì, EF / NHibernate sono accesso ai dati .. ma limitiamo il suo utilizzo al proprio assembly con una configurazione di repository generica. Questo assembly contiene anche tutti i nostri mapping NHibernate, Session factory, codice per la gestione di più database, ecc.

Ci riferiamo ancora ad esso come al "Livello di accesso ai dati", poiché l'intero assembly esiste per supportare il nostro ORM.

Probabilmente dovrei notare che la nostra app principale fa riferimento a 5 database, ha circa 4-500 oggetti / mappature di dominio e vari schemi. Quindi, questa configurazione ha senso per noi. Forse per un'app più piccola si salta questo assembly ma .. Sono un sucker per il codice organizzato e probabilmente lo farei comunque:)

    
risposta data 23.08.2013 - 18:38
fonte
2

Vedo EF e DAL come componenti separati in un sistema Enterprise. Il livello di accesso ai dati è un'astrazione che altri servizi utilizzano per eseguire la persistenza e la gestione dei dati. Tipicamente Entity Frameworks crea una buona API per l'interrogazione, l'aggiornamento, l'eliminazione e l'inserimento, ma al centro richiedono ancora una connessione diretta all'origine dati back-end. Quindi qualsiasi tipo di instradamento o firewall impedirà al EF di funzionare, richiedendo quindi la creazione di un componente di mediazione EF.

Ecco un esempio di alto livello che mostra dove DAL ed EF si adattano:

-------------    -------                                    ----------------    ------
| Service A | -> | DAL | -> { LOCAL / LAN / WAN ACCESS } -> | DAL BACK-END | -> | EF |
-------------    -------                                    ----------------    ------

È stata la mia esperienza che un design migliore non deve mai consentire alla logica aziendale o alle implementazioni di servizi l'accesso diretto al layer EF. Invece, fornire un'astrazione per lavorare con tutti i dati persistenti che consente di spedire le richieste sul filo o eseguirle localmente.

Questo design introduce tuttavia alcune astrazioni che perdono. Quindi dovrebbe essere considerato caso per caso.

Alcune domande da porre:

  • Tutti i componenti che accedono ai tuoi dati saranno in grado di ottenere una connessione all'archivio dati di back-end?
  • Il tuo EF ti consente di aggregare set di dati tra diversi tipi di archivi dati? Ad esempio, utilizzando un database SQL con MongoDB per i documenti.
risposta data 23.08.2013 - 18:35
fonte
1

Oggigiorno la questione se cambiare o meno l'archiviazione dei dati è più interessante di una volta, dato che la domanda potrebbe non essere se scambiare tra MS SQL o Oracle SQL, ma la domanda più grande se è possibile utilizzare le varie offerte di archiviazione dati NoSQL come repository di dati.

Se esistesse una seria possibilità di questo tipo di modifica, potrebbe essere utile mantenere il codice EF isolato all'interno del DAL in modo da poter introdurre un nuovo DAL in futuro che mappasse le richieste del repository su un database NoSQL. Potrebbe essere che un tale cambiamento finirebbe con una riscrittura globale della tua BLL comunque a causa di ipotesi relative al db che si insinuano naturalmente.

Allo stesso modo, EF all'interno di un DAL probabilmente renderebbe più semplice l'accesso ai dati per i test dell'unità di codice BLL.

Quindi il mio punto di vista è che EF (o altri ORMS) non necessariamente rende nullo il bisogno di un livello di accesso ai dati.

    
risposta data 04.09.2013 - 11:22
fonte