Questa domanda riguarda l'architettura del programma e la relazione tra DAL, Security e BLL nel caso in cui sia necessaria la scrittura simultanea in diversi oggetti di archiviazione. Lo indirizzo alle funzionalità di Microsoft SQL Server, ma è una domanda più comune e in generale non dipende dal DBMS usato.
Ho letto questo Q & A:
ma è più preoccupato per DAL vs Security rispetto a DAL vs BLL vs Security, e Sto cercando altri dettagli di implementazione di basso livello.
Esempio:
Abbiamo un DB relazionale. Abbiamo un pacchetto di applicazioni, accedendo a questo DB dalla rete (alcuni client SQL). Possiamo avere il pieno controllo sul server con DB.
In DB, abbiamo tre tabelle: tblCommonObjects, tblActionsA e tblActionsB.
Abbiamo due gruppi di utenti, GruppoA e GruppoB.
Dovremmo implementare la seguente logica:
- tblActionsA è possibile accedere solo a GroupA (lettura-scrittura)
- tblAzioniB è possibile accedere solo al gruppo B (lettura-scrittura)
- tblCommonObjects può essere letto in sola lettura da entrambi i gruppi, ma le scritture in tblCommonObjects possono essere eseguite solo insieme alla corrispondente scrittura in tblActionsA o tblActionsB. Per ogni scrittura in tblActionsA (B) possono essere presenti 0 o più scritture in tblCommonObjects
Il numero di azioni e gruppi aumenterà. Il numero di tabelle tblCommonObjects aumenterà e, in generale, CommonObject è una struttura complicata con oggetti secondari.
La logica aziendale, la sicurezza e la coerenza dei dati hanno la priorità sulle prestazioni.
Come vedo, può essere fatto in questi modi:
- Crea stored procedure uspWriteObjectActionsA e uspWriteObjectActionsB con parametro con valori di tabella o xml, contenente i dati da inserire / aggiornare tblCommonObjects. Analizzare i parametri all'interno dei proc memorizzati e inserire / aggiornare corrispondentemente. Concedere le autorizzazioni di scrittura solo ai processi memorizzati.
Professionisti: più o meno facili da implementare
Contro: facendo ciò, sposteremo definitivamente DAL (forse parzialmente) in SQL Server. I proc memorizzati potrebbero diventare complicati in caso di aggiunta di più gruppi e azioni
- Dividi tblCommonObjects in tblCommonObjectsA e tblCommonObjectsB. Crea vista tblCommonObjects per l'accesso in lettura.
Professionisti: più o meno facili da implementare
Contro: può essere complicato in caso di aggiunta di più gruppi e azioni. Uccide ASCIUTTO.
- Utilizza SOA e implementa alcuni livelli (ad esempio servizi SOAP o WCF) tra DBMS e applicazioni. Verifica le autorizzazioni in questo livello.
Pro: DAL può essere implementato in questo livello.
Contro: le autorizzazioni non vengono verificate in RDBMS e il sistema di autorizzazioni deve essere implementato manualmente. Soluzione più complicata, che coinvolge l'hosting SOAP o WCF. Test più complicati.
Come ho capito, la miscelazione di DAL e BLL è pratica comune e viene utilizzata, ad esempio, in Entity Framework.
Infine, la domanda: esistono alcune best practice per questo requisito di scrittura simultanea in diversi oggetti DB senza dare permessi a tutto e tutti e mescolando i livelli in monolith rock?