Memorizzazione della logica aziendale in tabelle anziché in stored procedure o applicazioni

Main thing is once the product is delivered, and if there is any need of changing the business logic then they want to be able to that themselves

Questo è potenzialmente un problema enorme . Devi essere in grado di circoscriverlo e determinare ciò che probabilmente vorranno cambiare, ad es.

1. passare da un paio di comportamenti? Quindi fornire una configurazione / flag per fornire tale commutazione. Puoi testarlo banalmente e distribuirlo con un piccolo problema
2. usa un'API che hai fornito e possono scrivere plug-in che (per esempio) ascoltano eventi / chiamate ben pubblicizzati, reagiscono a tali ecc. Puoi quindi documentarlo, testare quelle interfacce e dare ai tuoi utenti un API ben gestite su cui è possibile scrivere. Puoi controllare la visibilità dei dati, ecc. E gestirlo
3. Consenti loro di collegarsi alla tua soluzione e scrivere qualcosa contro la tua applicazione. A questo punto potresti anche dare loro il codice sorgente e abbandonare il controllo su questo. Non vuoi supportare un'applicazione contro la quale i tuoi clienti possono fare / cambiare quasi nulla

Più controllo ottieni, più potenziale hai per problemi di supporto e difficoltà nella gestione di questo.

Per risolvere il tuo problema specifico, la memorizzazione della logica di business nelle tabelle sarebbe un incubo da gestire (per i tuoi clienti e per te). Come hai intenzione di convalidare e strutturare questo? Le tabelle possono solo consentire ai mezzi di fornire semplici configurazioni s (ad esempio flag di impostazione, limiti numerici ecc. - a meno che non memorizziate alcuni script lì - che è completamente un altro problema)

Potresti creare una tabella che memorizza i corsi che possono essere presi l'uno con l'altro: CourseCombination (id, course1id, course2id). Quindi puoi creare una tabella che memorizzi un singolo valore che rappresenti il periodo di tempo in cui uno studente può prendere una qualsiasi combinazione di corsi: CourseCombinationTimeFrame.

Quindi, nella tua applicazione, crea un posto dove gli amministratori di sistema possono combinare i corsi e impostare il periodo di tempo in cui uno studente può prendere una qualsiasi combinazione di corsi. In questo caso avrebbero raggruppato la scrittura e la lettura e l'intervallo di tempo sarebbe di 2 settimane. Questo memorizza la scrittura e la lettura nella tabella CourseCombination e aggiorna il valore CourseCombinationTimeFrame a 2.

Ora, nella tua applicazione, crea un blocco di logica che convalida le selezioni del corso per gli studenti:

1. Interrogare la tabella delle combinazioni.
2. Quando lo studente sceglie un corso, controlla che il corso selezionato non violi le combinazioni.
3. Prendi la data minima di inizio dei corsi che lo studente ha selezionato.
4. Prendi la massima data di inizio dei corsi che lo studente ha selezionato.
5. Esegui una query sulla tabella degli intervalli di tempo.
6. Verifica che max - min sia all'interno del lasso di tempo.

Questo è solo un esempio. Ma tieni presente che non possono modificare la logica di business, solo i parametri della logica.

Se vogliono davvero il controllo sulla logica stessa, allora stanno praticamente chiedendo il codice sorgente, e presumo che abbiano un ragazzo IT che vuole essere in grado di personalizzare la post produzione del software. Se questo è il caso, assicurati che il tuo contratto sia molto chiaro su cosa stai consegnando e per quale pagamento. Idealmente, se vogliono cambiare la logica stessa, ti contatteranno per avere più lavoro. Dovresti provare a venderli con questa idea, perché sarai il meglio equipaggiato per apportare modifiche e sarà più economico per loro a lungo termine.

Questo approccio è piuttosto comune nelle applicazioni del flusso di lavoro. La logica aziendale potrebbe non essere presente nelle tabelle del database, ma può spesso essere caricata dinamicamente dal sistema e progettata dagli esperti di dominio. Le fondamenta del flusso di lavoro possono valere la pena dare un'occhiata.