A mio parere, si dovrebbe SEMPRE utilizzare un BLL (Business Logic Layer) tra il livello Web e il tuo DAL (Data Access Layer).
Mi rendo conto che per alcune delle domande rivolte più "semplici", la BLL da vicino imitare il DAL (ad es Fetch tutti i paesi, Fetch tutti i tipi di prodotto, ecc), ma per onesta, anche nel tuo esempio:
(Fetch tutti i clienti con cognome 'Atwood')
c'è "business logic" espressi qui - Un desiderio per i record di dati da filtrare per cognome, se non altro!
Implementando un BLL dall'inizio di un progetto diventa incredibilmente facile inserire o la validazione o la "logica" aggiuntiva come e quando può sorgere l'esigenza (e se il progetto è un'applicazione commerciale, tale necessità sarà quasi pari a sorge alla fine se non è lì all'inizio del progetto). L'aggiunta di logica aggiuntiva come ad esempio:
recuperare tutti i clienti che hanno speso oltre 10000 $ di quest'anno
o
Non consentire ai clienti con il cognome di 'Atwood' di acquistare oggetti su $ 1000
diventa significativamente più semplice quando è coinvolto un vero BLL, piuttosto che tentare di introdurre questa logica nel livello Web.
Si tenga presente che con il tipo di query di cui sopra, stiamo quasi certamente parlando di entità multiple e tabelle di database che dovranno unirsi con i rapporti specificamente definiti al fine di implementare questa funzionalità. Cercare di ottenere questo risultato manipolando direttamente il DAL diventa complicato poiché ti occuperai di più entità e classi. Un BLL qui semplificherebbe notevolmente il tuo codice di livello Web, dal momento che la BLL corrisponderà a encapsulate di quelle relazioni di entità dietro un'interfaccia notevolmente semplificata.
Questo "separation of concerns" diventa sempre più importante quando e se si presenta la necessità di cambiare l'interfaccia utente.
In almeno due occasioni separate ora, ho lavorato su applicazioni web commerciali con un'interfaccia utente del sito web, e sono stati infine chiesto (a causa di esigenze di business derivanti da clienti che cercano una maggiore integrazione all'interno dei loro prodotti software) per la produzione di un'interfaccia web service che offre la stessa identica funzionalità del sito web.
Se avessi incorporato qualsiasi logica di business all'interno del mio livello Web, avrei dovuto duplicare e riscrivere quella logica quando implementavo il mio servizio web. In effetti, mi sono assicurato che tutta la logica aziendale fosse incapsulata all'interno delle classi BLL, il che significava che dovevo semplicemente progettare una serie di chiamate al metodo dell'interfaccia del servizio web e collegarle alle chiamate ai metodi sulle classi BLL (in realtà usavo il Facade Design Pattern in luoghi per semplificare l'API del servizio Web).
In totale, non riesco a pensare a NON includere un livello BLL tra il mio DAL e il mio livello Web.
Al modo più semplice, quando il BLL "imita" il DAL, sì, sembra che ci sia una duplicazione di codice e funzionalità, tuttavia, pur essendo un po 'più di digitazione, questo rende anche relativamente facile da implementare.
Quando è più coinvolto (ad esempio quando esiste una logica aziendale significativa fin dall'inizio), la separazione delle preoccupazioni aiuta a ridurre la ripetizione (il principio DRY) e allo stesso tempo semplifica notevolmente la manutenzione futura e continua.
Naturalmente, questo presuppone che stai facendo tutto questo "a mano". Se lo desideri, puoi semplificare notevolmente i livelli DAL/BLL/UI utilizzando uno ORM di cui ce ne sono molti! (ad esempio LINQ-to-SQL/Entities, SubSonic, NHibernate ecc.)
Bellissima domanda! –