Applicazioni "rule-based" altamente scalabili e dinamiche?

Userei WF o Drools se stai cercando di creare un'astrazione con cui i non programmatori potrebbero lavorare per sviluppare regole di business. Tuttavia, se hai a che fare con i programmatori che l'astrazione di WF non vale il tempo necessario per sviluppare una soluzione, non riesco a vedere il valore aggiunto per il tuo investimento.

Un database è un buon modo per mantenere regole che potrebbero cambiare molto, ma lasciatemi suggerire una possibile alternativa (non necessariamente migliore, ma un'alternativa).

1) Separa la logica di business nel suo stesso livello (dll) - astrarre come stai chiamando con alcune interfacce (guarda i modelli di strategia e osservatore) i.e IRuleEvaluator.Evaluate (string myParams).

2) Ora puoi creare classi discrete per ogni regola (se necessario) e i test delle unità di accompagnamento.

3) Ora per il Pièce de résistance, cablate tutto dietro le quinte in un container di IOC: la stessa dll e l'istanza del programma di valutazione regole. In questo modo il tuo valutatore di regole viene costruito attraverso la configurazione in fase di esecuzione: nulla è codificato insieme.

Questo approccio è molto dinamico (forse troppo dinamico per alcuni gusti) - ti permetterà di avere effettivi test unitari discreti per tutte le tue regole. Se è necessario ridistribuire o modificare una regola, è possibile rilasciare una nuova DLL, modificare il file di configurazione IOC, riavviare e verificare, oppure ripristinare la modifica se qualcosa non va, senza modificare il codice di base (proprio come un Banca dati). E a differenza di un database, manterrà la logica e il codice dell'applicazione sotto un unico ombrello, anziché metà scritta in C # e metà in SQL.

Ci sono due casi di regole che ho visto. Nella maggior parte dei casi, la regola stessa non è molto volatile (quasi fissa), ma i dati su cui viene presa la decisione possono essere modificati dagli utenti aziendali. In questo caso sono generalmente sufficienti schemi di progettazione semplici per incapsulare ogni regola con la lettura dei dati di riferimento da DataBase. Quindi fornire un frontend per modificare i dati di riferimento delle regole.

Gli altri casi in cui la logica della regola stessa può essere modificata dinamicamente. Un approccio sarebbe utilizzare IronPython o altri linguaggi dinamici (in .Net 4) per implementare le regole e caricarle dinamicamente al momento dell'esecuzione. Questo è un compromesso poiché dovrai ancora richiedere ai programmatori di cambiare le regole.

Se vuoi davvero che le regole siano modificabili dagli utenti aziendali, la creazione di DSL per il tuo dominio aziendale è un approccio da adottare. Questa è un'impresa complessa però.

Infine, utilizzare il flusso di lavoro o BizTalk può aiutare se le regole si adattano ai modelli di trasformazione / orchestrazione.

Se stai progettando un'applicazione "basata su regole" altamente scalabile in cui le regole sono soggette a frequenti cambiamenti dal business, allora considera i prodotti BRMS leader del mercato come: 1. IBM WODM 2. Advisor FICO BLAZE 3. Drools (open source)

Ho lavorato su grandi applicazioni commerciali con un approccio BRMS che le rende altamente scalabili e facili da mantenere, oltre a renderle molto flessibili con il downtime ZERO fino alla produzione. Rende gli affari felici. :)

Sto presumendo che tu non ti riferissi strettamente alle operazioni lato client e che siano in .Net dato che hai citato c # ...

Se sei sul framework 4 hai il DLR (dynamic language runtime) o su qualsiasi framework se stai memorizzando le regole in sql puoi anche elaborarle lì oppure puoi sempre usare linq dinamico nei framework > 3 o scrivere le diverse funzioni come assembly che possono essere caricati per nome in fase di esecuzione attraverso un carico di assembly.

Non tutti sono eleganti in molti casi, ma ho dovuto usarli tutti a volte.

Una cosa che viene in mente è Windows Workflow Foundation , che può essere utilizzata insieme a ASP.NET ma sarebbe in esecuzione sul lato server (quindi potrebbe non essere applicabile a quello che stai facendo). In Java land c'è jBPM (gestione dei processi aziendali) che viene eseguito anche sul lato server.

Dal momento che tali soluzioni probabilmente non sarebbero adatte a te , la cosa migliore da fare potrebbe essere quella di implementare quelle regole aziendali in un semplice vecchio codice (usando javascript, C # o qualsiasi altra cosa migliore per il lavoro) e aspettarsi che il codice di programmazione debba essere aggiornato quando si verificano cambiamenti di progettazione. L'utilizzo di schemi di progettazione orientati agli oggetti renderà il codice facilmente estensibile. Se scrivi bene il codice, lo sforzo necessario per modificarlo in futuro dovrebbe essere minimo.

Se le tue regole sono tutte di un modulo

if <condition>
then <action>
[else <action]

Potresti usare Drools.NET o un'altra implementazione di Rete come iLog.