Ho una domanda di design generica relativa alle applicazioni aziendali, ma penso che anche gli sviluppatori di software di altri tipi di progetti possano avere esperienza con questo.
Lo scenario segue: hai un database e stai per scrivere un'applicazione che fornisce l'accesso ai suoi dati. Il database contiene anche dati sugli account utente, i loro ruoli e autorizzazioni. Il problema è che anche altri processi stanno accedendo al database e ognuno di questi processi può modificare qualsiasi dato in qualsiasi momento (ad es. Cancellare un utente).
In altri progetti ho avuto accesso esclusivo al database e quindi di solito ho avvolto il database con un livello che esponeva le funzionalità del dominio correlato in uno stile SOA. Questo wrapper disponeva di un modello di dominio ricco e poteva utilizzare la memorizzazione nella cache dei dati del database perché era a conoscenza di eventuali modifiche (intercettando eventi di dominio, CQRS) che potevano modificarlo.
Con un database condiviso non so come affrontare il progetto. Immagina questa situazione:
- La richiesta HTTP arriva all'applicazione e devi autenticare questa richiesta.
- Si interroga il database per l'account utente richiesto e i relativi dati di accesso. Se le credenziali fornite corrispondono, viene stabilita una sessione (ad es. In ASP.NET un cookie sicuro viene inviato al client).
- Ma poi arriva una richiesta successiva da parte di quell'utente. Il problema è che invece di fare qualcosa di utile in questo momento, sembra che sia necessario verificare se l'account utente associato esiste ancora nel database. Qualsiasi informazione può smettere di essere valida in qualsiasi momento perché altri processi possono alterare il database.
Questo è ovviamente un problema più generico. I dati possono non solo cambiare tra richieste ma anche tra due chiamate di database separate. La risposta facile qui è usare le serrature / transazioni. Ma la verità è che questo richiederebbe enormi cambiamenti allo schema del database. Ad esempio, ogni account utente richiederebbe una colonna aggiuntiva "InUse", ma si tratta solo di uno scenario molto semplice. Posso immaginare che sia necessario creare tabelle completamente nuove. Inoltre, le transazioni si estendono in genere su molte richieste HTTP e pertanto rendono il database inutilizzabile per lunghi periodi di tempo per altri utenti.
Ho letto il libro PoEAA e sono ben consapevole delle varie tecniche di sincronizzazione. Quello che sto cercando qui è qualche tecnica o metodologia generica su come ottenere il cosiddetto "progetto abbastanza buono" che non richiede modifiche allo schema del database e può gestire le situazioni menzionate in cui qualsiasi cosa può cambiare tra due richieste.
In questo momento penso che andrò con il seguente approccio: autenticherò l'utente. Quindi not eseguirò i controlli successivi per assicurarmi che non sia stato eliminato nel frattempo. Ma quando eseguo un'operazione che si basa sull'esistenza dell'utente, riceverò un'eccezione e deduco che l'utente deve essere stato eliminato. La risposta sarà quindi una sorta di messaggio di errore o pagina di errore.
Sono sicuro che questo è un problema comune che molti di voi devono aver incontrato. Apprezzerò qualsiasi soluzione o anche un riferimento a qualche libro o carta. Grazie.