A che serve un Business Logic Layer (BLL)?

Nel leggere le buone pratiche per le applicazioni di database mi sono imbattuto spesso in sostenitori dei cosiddetti "livelli di logica aziendale" e sto cercando di decidere se è meglio che il mio progetto ne usi uno (è un piccolo progetto personale). Il mio problema risiede nel fatto che non riesco a pensare a nulla che il BLL possa fare che il DAL non può già gestire (eseguendo query e mappando i risultati sugli oggetti), quindi il mio BLL chiama semplicemente il DAL senza fare nulla da solo.

Forse mi sbaglio esattamente su cosa dovrebbe fare anche il DAL. Ma a prescindere, che tipo di funzionalità ci si dovrebbe aspettare da un BLL in un'applicazione di gestione di database?

Per le mie applicazioni più piccole, il mio BLL di solito inizia come pass-through al DAL. Sto bene con quello. Mentre "scopro" le regole aziendali, BLL è dove le ho messe. Finisco anche per trovare molte cose necessarie nel BLL mentre scrivo i miei test. Per le mie app personali, creo le regole di business e BLL è ancora dove le ho messe. Per me, BLL è qualcosa che cresce nel tempo. Più a lungo ho lavorato su un progetto, più grande è il BLL.

Prenderei in considerazione la combinazione di BLL e DAL per un piccolo progetto? Potrei, tranne per il fatto che cambio le tecnologie DAL ogni volta che cambio acconciature, e mi piace avere qualcosa per isolare il mio codice cliente da quello.

Il BLL gestirà le cose che fanno parte del dominio aziendale, non una parte del database e non una parte dell'interfaccia utente (di solito). Ad esempio, utilizzando l'età di un cliente per determinare se si qualificano per uno sconto speciale per senior. Il DAL non dovrebbe farlo, dovrebbe semplicemente recuperare i dati dei clienti e quindi archiviarli con i dati di sconto dopo che BLL ha svolto il proprio lavoro. Il DAL dovrebbe concentrarsi maggiormente sul CRUD. Nelle piccole applicazioni, le due preoccupazioni possono sovrapporsi.

Andrea,

I livelli di logica aziendale sono ciò che si ottiene quando si esegue lo sviluppo guidato dal dominio e ci si concentra sulle attività principali del dominio. Se elimini il livello di presentazione (gui, web) e il livello di infrastruttura (db, connettività di rete, ecc.) Hai le attività principali che fanno parte del tuo dominio, come depositare denaro su un conto bancario. Ora, se hai modellato il tuo livello aziendale e lo hai isolato da presentazione e infrasturcture, puoi portarlo facilmente ad altri usi, come web o dispositivi mobili. È un modo pulito di pensare allo sviluppo e da quello che ho visto, sfortunatamente non è stato preso sul serio.

Consiglio di mettere le mani su Eric Evans - Domain Driven Design, che è un buon libro che giustifica la focalizzazione degli sforzi di sviluppo sul dominio. Certo, è un po 'una lettura secca a metà strada, ma aumenta lo slancio e ha alcune forti convinzioni su ciò che gli sviluppatori stanno facendo di sbagliato con i sistemi di oggi.

Non c'è nulla che dica che DEVI avere un certo numero di livelli o livelli. Tutto dipende dalla complessità del tuo progetto. Dai un'occhiata a molte delle app di esempio MVC, come la cena per nerd o il negozio di dischi .. usano tutti 2 livelli perché per le applicazioni che hanno una logica di elaborazione molto ridotta, non ha senso.

Tuttavia, anche se l'app è di piccole dimensioni, potrebbe trarre vantaggio dall'astrarre il livello dati dal livello di presentazione tramite un terzo livello che normalmente sarebbe un livello aziendale. Ciò ti consente di apportare modifiche in un unico posto, anziché in tutto il livello di presentazione.

Supponiamo che tu decida di cambiare il tuo ORM da Linq a SQL in Entity Framework (o nhibernate). Probabilmente sarà più facile cambiarlo nel livello aziendale piuttosto che nel livello presentazione, poiché la presentazione tende ad accoppiarsi strettamente al suo modello di presentazione.

Se capisci MVC, cioè .. Model View Controller, puoi pensare all'architettura della tua applicazione in termini simili. Il modello è analogo al livello dati, il livello Presentazione è la vista e il livello aziendale è il controller.

Completando la risposta di Desolate Planet su Domain Driven Design:

Dai un'occhiata anche a The Onion Architecture , che è molto in linea con i concetti di Domain Driven Design.

Si noti come il "Livello" della logica di business sia il fulcro della cipolla e ogni livello di infrastruttura (come il livello di accesso ai dati) siano le sue dipendenze esterne. Questo aiuta molto a testare, perché dovresti essere in grado di deridere ogni dipendenza dell'infrastruttura esterna e testare completamente la logica del tuo dominio.

Secondo me: il livello della logica di business è il luogo in cui vive la "pura soluzione concettuale". Il resto sono solo dettagli di implementazione infrastrutturale.

Tuttavia, alcune applicazioni potrebbero non aver bisogno di questo tipo di architettura. Se tutte le tue applicazioni sono operazioni CRUD di insiemi di dati, la tua "soluzione concettuale pura" potrebbe essere praticamente vuota e tutto ciò di cui hai bisogno è un front-end di modifica del database. In tal caso probabilmente dovresti stare meglio concentrandoti solo sui livelli DAL e UI.

La risposta a questa domanda è (IMHO): "posso sostituire completamente il mio DAL e non dover riscrivere il mio codice di logica aziendale"?

Pensalo come il tuo livello di presentazione: è abbastanza comune pensare di cambiare la GUI per una diversa, una GUI desktop spessa viene scambiata per un client Web, che viene scambiato per un'app per iPhone. Non è così comune pensare in questo modo per BLL / DAL in quanto non vengono mai scambiati, tranne forse per qualcosa di molto simile (ad esempio un DB SQL Server sostituito con uno MySQL), ma se immagini di dover cambiare il tuo DB in un archivio distribuito servizio a cui si accedeva tramite un'API, è possibile avere un'idea più chiara di dove si incontrano i livelli.