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.