Sviluppo di applicazioni con controlli e processi completamente dinamici basati sul database

Il modo in cui viene normalmente eseguito è con i ruoli dell'utente e una matrice di accesso ai ruoli .

Ogni utente ha un ruolo, salvato nel database insieme al nome utente, password, ecc.

Quindi, c'è una matrice di accesso al ruolo bidimensionale da qualche parte, che specifica per ciascun ruolo e per ciascun campo dello schermo quale tipo di accesso deve essere avuto dagli utenti che hanno quel ruolo specifico su quel campo specifico dello schermo. L'accesso potrebbe essere:

• "none", il che significa che il campo non deve essere mostrato agli utenti di questo ruolo
• "di sola lettura", il che significa che il campo deve essere visualizzato, ma non modificabile, e
• "lettura-scrittura", il che significa che il campo deve essere visualizzato e modificabile.

In una variante di questo schema, ogni utente può avere più ruoli, quindi l'accesso che un utente ha a un determinato campo viene calcolato per essere l'accesso massimo consentito da qualsiasi ruolo detenuto dall'utente. Quando viene utilizzata questa variazione, i "ruoli" possono essere chiamati "gruppi", nel senso che un utente può appartenere a più gruppi contemporaneamente.

In un'altra variazione ancora più sofisticata, ma ancora più complicata, introduciamo le autorizzazioni come fase intermedia, sostituendo la matrice di accesso ai ruoli con una matrice dei permessi dei ruoli molto più piccola. In questo scenario, ogni campo ha un'autorizzazione necessaria per l'accesso "di sola lettura" e un'altra autorizzazione richiesta per l'accesso "lettura-scrittura". (Queste autorizzazioni richieste possono essere codificate per ogni campo: non è necessario che siano configurabili.) Se un utente ha un ruolo che non ha nessuna delle autorizzazioni richieste, l'utente non vede affatto il campo. Quindi, ad esempio, un campo "indirizzo email" potrebbe richiedere alcune autorizzazioni "visualizza informazioni sensibili" per avere accesso "di sola lettura" ad esso e alcune autorizzazioni "modifica informazioni sensibili" per avere "lettura-scrittura" accesso ad esso. Ogni utente ha o non ha queste autorizzazioni a seconda del suo ruolo. Presumibilmente ci saranno molti campi che richiedono le stesse autorizzazioni per lo stesso tipo di accesso, quindi il numero totale di permessi sarà molto piccolo, il che a sua volta significa che la matrice dei permessi di ruolo sarà piccola.

Quindi, uno di questi approcci dovrebbe risolvere bene il tuo problema. In realtà, sarei disposto a scommettere che sono più vicini a ciò che il cliente desidera davvero realizzare: probabilmente non vogliono personalizzare il tipo di accesso di ogni singolo utente a ogni singolo campo dello schermo, probabilmente hanno alcuni gruppi di utenti e possibilmente alcuni gruppi di campo vagamente in mente, e vogliono diversi gruppi di utenti per avere diversi tipi di accesso a diversi gruppi di campi.

La matrice di accesso ai ruoli o la matrice dei permessi di ruolo può essere archiviata nel database, oppure possono essere archiviati in un file di configurazione esterno, oppure, se stai costruendo l'interfaccia utente usando un linguaggio di scripting come PHP, possono anche essere inserito direttamente nel codice e lasciare che il cliente modifichi il file sorgente PHP per modificare le autorizzazioni.

Ho esperienza con grandi prodotti CRM / ERP creati in questo modo. È fattibile, ma richiede molto più tempo e la funzionalità sarà limitata. Se questo genere di cose viene proposto solo per il controllo degli accessi, non penso che ne valga la pena.

Alcuni aspetti negativi:

• Tutti i tipi di controlli che si desidera utilizzare devono essere personalizzati in base a supporta le informazioni persistenti nel database. Se è più che una coppia tipi di caselle di testo, quindi stai osservando un enorme sforzo.
• Le dipendenze tra i controlli sono difficili da implementare e lo saranno limitato nella funzionalità.
• Più difficile da eseguire il debug e codice più complicato.

Ti consiglio di combattere più duramente con il cliente e persuaderlo, che è molto meglio salvare solo la refferenza del controll nel database. Ad esempio, è possibile aggiungere un livello al software, che impedisce di visualizzare il controllo quando il nome non è stato trovato nel DB e lo stesso obiettivo sarà raggiunto.

Prima di tutto, tieni presente l'effetto Inner platform e fai tutto ciò che è in tuo potere per evitarlo. Anche se segui il percorso ultra-flessibile, la chiave per riuscire effettivamente è ironicamente comprendere appieno le sue insidie.

Tuttavia, se una piattaforma di questa flessibilità è veramente ciò che è necessario / cosa sa la direzione pensa che voglia ... almeno evitare di reinventare il DB all'interno del DB. I database sono dinamici e l'applicazione è in grado di creare le proprie tabelle e di esaminare le loro strutture, evitando di creare una tabella di valori / chiavi. Per fare ciò, crea una classe MetaRepository che sia responsabile della creazione / lettura delle strutture delle tabelle dei tuoi tavoli al volo.

Di solito avere un livello di business logic è una buona idea, ma qui, potrebbe essere di intralcio dal momento che aggiungere una specifica logica di business per un'entità generata dinamicamente potrebbe rivelarsi molto difficile.

MVC è ottimo, anche se devi utilizzare un modello di visualizzazione dinamica. Non ho mai visto un'applicazione GUI che non beneficia di MVC.

Tornando alla tua ultima domanda, FAI TUTTO POSSIBILE EVITARE DI ANDARE IN QUESTO PERCORSO! Esiste già un'applicazione che può essere configurata per fare tutto il necessario per ... si chiama compiler di codice ...

Il mio cliente vende un sistema di gestione dei casi che funziona esattamente in questo modo. Tutti gli accessi a tutti i campi sono controllabili. È perfettamente utilizzabile, sebbene per motivi di prestazioni le autorizzazioni siano memorizzate nella cache dell'applicazione e l'aggiornamento del database non abbia un effetto immediato (ma un meccanismo di aggiornamento rapido potrebbe essere implementato con i trigger, se necessario). Sono sicuro che ci sono molti altri prodotti che funzionano in modo simile.

Per renderlo utilizzabile, dovresti strutturare le autorizzazioni dei campi in qualche modo, ad esempio raggruppandole in ruoli, come altri hanno indicato.