A cosa serve un Business Logic Layer (BLL)?

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

Considererei la possibilità di combinare BLL e DAL per un piccolo progetto? Potrei, a parte il fatto che cambio le tecnologie DAL più spesso di quando cambio le pettinature e mi piace avere qualcosa da isolare dal mio codice client.

Il BLL gestirà 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 fare questo, dovrebbe semplicemente recuperare i dati del cliente, e quindi archiviarlo con i dati di sconto dopo che BLL ha fatto il suo lavoro. Il DAL dovrebbe concentrarsi maggiormente su CRUD. Nelle piccole applicazioni, le due preoccupazioni potrebbero sovrapporsi.

Andrew,

I livelli della logica aziendale sono ciò che si ottiene quando si esegue lo sviluppo basato sul dominio e si concentrano sulle attività principali del dominio. Se togli il livello di presentazione (gui, web) e il livello dell'infrastruttura (db, connettività di rete, ecc.) Hai le attività principali che fanno parte del tuo dominio, come il deposito di denaro su un conto bancario. Ora, se hai modellato il tuo livello aziendale e lo hai isolato dalla presentazione e dalla infrasturtura, puoi portarlo facilmente ad altri usi, come i dispositivi web o mobili. È un modo pulito di pensare allo sviluppo e da quello che ho visto, purtroppo non è stato preso così seriamente.

Suggerirei di mettere le mani su Eric Evans - Domain Driven Design, che è un buon libro che giustifica concentrare gli sforzi di sviluppo sul dominio. A dire il vero, è un po 'una lettura asciutta a metà, 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'è niente che dice 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 .. tutti usano 2 livelli perché per applicazioni che hanno una logica di elaborazione minima, non ha senso.

Tuttavia, anche se la tua app è piccola, potrebbe trarre vantaggio dall'astrazione del livello dati dal livello di presentazione tramite un terzo livello che normalmente sarebbe un livello aziendale. Ciò consente di apportare modifiche in un singolo luogo, piuttosto che su tutto il livello di presentazione.

Supponiamo che tu decida di cambiare il tuo ORM da Linq a SQL in Entity Framework (o nibernetico). Sarà probabilmente più facile cambiarlo nel livello aziendale rispetto al livello di presentazione, poiché la presentazione tende a unirsi strettamente al suo modello di presentazione.

Se capisci MVC, ovvero .. Model View Controller, puoi pensare all'architettura dell'applicazione in termini simili. Il modello è analogo al livello dati, il livello Presentazione è la vista e Business Layer è il controller.

Compilando La risposta di Desolate Planet about Domain Driven Design:

Guarda anche The Onion Architecture , che è molto allineato con il Domain Driven Design concetti.

Si noti come il "livello" di Business Logic è il nucleo della cipolla e ogni livello di infrastruttura (come il livello di accesso ai dati) sono le sue dipendenze esterne. Questo aiuta a testare molto, perché si dovrebbe essere in grado di prendere in giro ogni dipendenza dell'infrastruttura esterna e testare completamente la logica del dominio.

A mio parere: lo strato di business logic è 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 del set 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 questo caso, probabilmente dovresti concentrarti solo sui livelli DAL e UI.

La risposta a questa domanda è (IMHO): "Posso sostituire completamente il mio DAL e non dover riscrivere nessuno dei miei codici di logica aziendale"?

Consideralo come il tuo livello di presentazione - è abbastanza comune pensare di cambiare la GUI per una diversa, una spessa interfaccia grafica per desktop viene scambiata per un client web, che viene scambiato per un'app per iPhone. Non è così comune pensare in questo modo a BLL / DAL perché non vengono mai scambiati, tranne forse per qualcosa di molto simile (ad esempio un DB SQLServer sostituito con uno MySQL), ma se immagini di dover cambiare il DB in uno spazio di archiviazione distribuito servizio a cui è stato effettuato l'accesso utilizzando un'API, potresti avere un'idea più chiara di dove si incontrano i livelli.