Sto cercando di decidere come (o se) il mio Data Access Layer dovrebbe occuparsi delle protezioni di sicurezza e integrità esistenti sul database. L'architetto in me dice che separation of concerns è una priorità e la duplicazione dei compiti è dispendiosa quindi dovrei lasciare il database per gestire il controllo degli accessi e lasciare che il Object Relational Mapping sia un mediocre idiota tra business logic e persistence strati. Ma il DBA in me non apprezza l'idea di creare modelli che consentano ad altri sviluppatori di tentare di gestire i dati sottostanti in modi che non dovrebbero (come definito da vincoli, relazioni e sicurezza dell'account sul database).
Quanto "intelligente" dovrebbe essere il mio DAL? Il mio DAL dovrebbe tenere conto dei privilegi di accesso (come chi può leggere / scrivere) per creare una versione accessibile orientata agli oggetti del mio livello di persistenza? O dovrebbe essere un vero pass-through e dovrei aspettarmi che il mio livello aziendale rispetti la sicurezza a cui potrebbe non avere visibilità immediata? Più probabilmente qualcosa in mezzo?
In altre parole ... se ho un account di database che fornisce solo SELECT (sola lettura) diritti alla tabella MYTABLE , se l'oggetto Data Access Layer per MYTABLE riflette queste autorizzazioni in quali metodi sono permesso di essere chiamato contro questo modello? Che dire quando ho una singola entità a cui si può accedere in modi diversi a seconda di quale account (o servizio) lo sta colpendo? Devo avere più modelli degli stessi dati sottostanti?
Se non riesci a capire dal mio testo sopra, preferirei avere un DAL più intelligente che assicuri che i miei controlli del database siano almeno in qualche modo rispettati (senza la necessità di lanciare un sacco di errori di runtime). Ma non so dove tracciare la linea tra "business logic" e "data access logic" e odio l'idea di duplicare il lavoro.