Livello di accesso ai dati, Business Class o Deposito?

Non c'è utilità per un BAL se tutto ciò che deve fare è alimentare le stringhe di accesso al database. Potresti anche scoprire che c'è troppa logica aziendale contenuta nelle stored procedure.

Se vuoi accedere ai dati nella tua logica di business, chiamala in un altro modo.

Quando si ha a che fare con un'architettura con un DAL e un livello logico aziendale separati, le stored procedure e SQL non appartengono al livello della business logic. A rigor di termini, tale livello dovrebbe essere indipendente dal modo in cui i dati vengono archiviati e recuperati e dovrebbe essere responsabile solo della manipolazione delle istanze restituite dal DAL, dell'applicazione delle regole aziendali e dell'esecuzione della convalida.

Per quanto ciò che è pratico, però, le linee spesso sfocano, poiché spesso è difficile bilanciare l'efficienza (la velocità di esecuzione del codice) e la convenienza (quanto velocemente è possibile produrre codice funzionante) rispetto alla progettazione ideale. Se hai filtri complessi come risultato di regole nel tuo livello aziendale, sarebbe estremamente inefficiente restituire tutto dal tuo DAL e filtrare nel livello aziendale, sebbene ciò seguirebbe la stretta separazione tra i livelli. E sarebbe troppo lungo e sarebbe un incubo di manutenzione scrivere una funzione separata per ogni possibile modo di filtrare i dati. Per un progetto di grandi dimensioni, la soluzione è spesso quella di introdurre un modo per creare una classe "richiesta" (o "query") personalizzata che viene passata al DAL, che restituisce risultati basati sull'oggetto personalizzato, ma questo è eccessivo per un piccolo progetto (a meno che non si utilizzi un ORM come Entity Framework, che espone il proprio repository come una raccolta di IQueryable<T> , che consente di creare la query senza preoccuparsi di come verrà effettivamente eseguita contro l'archivio dati).