Come personalizzare l'app Web (pagine e interfaccia utente) per diversi clienti

Se i tuoi dati normali sono conservati in un database, non sono del tutto sicuro del motivo per cui vorrai avere tutte le informazioni specifiche del cliente in un file xml. Spostalo nel database.

Successivamente, ci sono molti diversi tipi di motori di regole là fuori. Considerando che stai usando asp.net potresti voler guardare a Windows Workflow almeno per alcuni di questi. Puoi leggere quanto segue: link

Molto tempo fa ho usato un prodotto chiamato Haley Rules per guidare un'app web c #. Controllava tutto dagli schermi disponibili fino ai campi che apparivano e se erano richiesti o meno. Ci è voluto un po 'per mettere la squadra a bordo con come funzionava, ma una volta che ciò è accaduto portando un nuovo cliente è stato estremamente semplice. Haley da allora è stato divorato da Oracle, ma probabilmente era il migliore in assoluto.

Altre persone a cui potresti essere interessato sono NxBRE e anche nCalc . NxBRE è un vero motore di regole che è una porta di uno costruito per java. nCalc d'altra parte non è un motore di regole di per sé. Tuttavia, se puoi esprimere la tua logica in semplici dichiarazioni booleane, allora è estremamente veloce. Attualmente sto usando questo per guidare il flusso di pagine in una delle nostre applicazioni.

Alcuni commerciali includono: FlexRule , iLog

Il tuo motore di regole esistente supporta la tua applicazione web, il che significa che soddisfa già le tue esigenze. Puoi usare altri "Rule Engine" come il flusso di lavoro di MS, ma IMO può anche finire con una situazione difficile da maitain.

Diciamo che c'è il portale di registrazione. Raccoglie informazioni generali dell'utente e le salva in un database. Semplice. costruiamo un protal per un client con diverse ASCX e regole. Quindi per un altro client, aggiungiamo più regole e più controlli a queste ASCX. Lavorando in questo modo, prima o poi raggiungeremo il cliente finale. A quel tempo il codice base è difficile da maitain e gli sviluppatori si sono persi in molte regole. È quello che mi è successo.

Quindi, per me, non si tratta di quale motore di regole utilizzare.

Allora come?

Ho sollevato una domanda e una delle risposta ha senso per me (non è una risposta scelta). In questa risposta, il ragazzo ha menzionato che tipo di azienda sei. Nella tua domanda è più simile a quale dipartimento sei o vuoi separare i tuoi team di sviluppo.

Se ti trovi in un gruppo di archetect, crea un framework con un motore di regole. Crea un portale di registrazione di base come portale di esempio. Fai DAO, BO disaccoppiato con UI (livelli separati).

Se ti trovi in un team personalizzato, crea un controllo utente personalizzato (non riutilizzare questi controlli utente nella versione di base). Quello che ricreerete è solo l'interfaccia utente, è comunque possibile utilizzare DAO, BO poiché non sono definiti nel controllo utente, ma si trovano su altri livelli. In questo modo puoi ottenere la libertà di definire le regole specificate dal cliente senza preoccuparti di contaminare le regole di altri clienti o di introdurre nuovi bug nelle registrazioni di altri client.

Comprendi che non è come una risposta alla tua domanda. Ad ogni modo è il mio pensiero dopo aver limitato xp di lavorare su un'applicazione web multi-client basata su regole del motore.

Quando le esigenze dei singoli clienti sono così profondamente differenti che la funzionalità condivisa rappresenta meno del 50% delle funzionalità per le esigenze di un determinato cliente, allora ci sono solo due modi principali per gestire questo:

Scrittura di una pagina personalizzata per ogni singolo cliente

Questo tende a essere a volte un'opzione sgradevole sia per la gente tecnica che per gli uomini d'affari e di vendita. Può anche essere sgradevole se il cliente si rende conto che stai eseguendo un sacco di sviluppo personalizzato per soddisfare le loro esigenze.

Considerazioni tecniche

Come sviluppatore, l'alta manutenibilità è uno degli obiettivi centrali che dovremmo sforzarci di realizzare, quindi la scrittura di pagine personalizzate per singoli clienti è in contrasto con questo obiettivo. Supponiamo che debba essere aggiunta una funzionalità comune che dovrebbe interessare tutti i clienti, ora questa modifica deve essere implementata manualmente per tutti i client e testata per ogni client che ha un'implementazione separata per quella pagina. Se hai un numero di clienti, questo può semplicemente essere insostenibile nel tempo.

Considerazioni aziendali

Dal punto di vista del business come ISV, ci piace costruire un prodotto, che in genere è più coinvolto del solo software. La vendita di un prodotto software implica che, in quanto fornitore, disponiamo di un unico pacchetto in grado di soddisfare tutte le esigenze dei clienti con una personalizzazione minima o nulle rispetto al nucleo del prodotto stesso.

Quando è necessario che le personalizzazioni del prodotto avvengano per soddisfare un cliente, il prodotto potrebbe essere inadatto o potrebbe essere stato progettato male. Può darsi che la soluzione che viene venduta non possa in realtà essere considerata un prodotto, ma viene semplicemente commercializzata in quel modo. Il business del software può essere complicato come questo ed è il motivo per cui proprietari di prodotti e addetti alle vendite fanno i soldi grandi perché questa formula vincente per il successo nella vendita di software può essere straordinariamente difficile. Se non lo commercializzi correttamente, o non crei correttamente un'idea di prodotto, allora non puoi vendere o potresti vendere e non essere in grado di mantenere le promesse.

Considerazioni sul cliente

A tutti i clienti piace sentirsi dire che stanno ottenendo un buon affare e quando acquistano un prodotto software vogliono credere che tutti i loro bisogni siano soddisfatti. Questo è il motivo per cui i prodotti software vendono più facilmente e facilmente rispetto allo sviluppo di software personalizzato, anche quando le esigenze del cliente sono così intrinsecamente specifiche che nessun prodotto del genere potrebbe mai esistere dallo scaffale.

Se il cliente scopre che stai eseguendo una buona quantità di sviluppo di software personalizzato solo per le sue esigenze, allora perde la fiducia che il tuo prodotto abbia mai avuto la possibilità di consegnare e che alla fine pagherà a caro prezzo nel lungo termine per coprire i costi di sviluppo personalizzati.

Quando è una buona idea

Se il software si trova in un mercato di nicchia con una piccola quantità di clienti e opportunità di crescita limitate, lo sviluppo di pagine Web personalizzate per funzionalità specifiche è probabilmente la scelta migliore.

Motore di regole e layout basato su XML

Fondamentalmente si identificherebbe la funzionalità di base da incorporare nelle pagine e qualsiasi cosa specifica del cliente dovrebbe essere definita attraverso un layout personalizzato e un motore di regole che consenta di personalizzare le esigenze del client al di fuori della base di codice. Le considerazioni di progettazione tecnica per questo sono che

Considerazioni tecniche

Il cliente ha bisogno a questo punto di diventare una modifica dello schema tramite XML piuttosto che un costoso incubo di manutenibilità di un cambio di codice. Il controllo dei layout tramite XML per definire la vista, l'XML da legare al modello e le regole per definire il controller consentiranno un'architettura solida che si ridurrà man mano che la tua azienda cresce e mantengono un accoppiamento libero, un'elevata coesione e un'elevata manutenibilità. Questi documenti XML possono essere facilmente mantenuti tramite un NoSQL o anche sistemi RDBMS tradizionali.

Considerazioni aziendali

Limitare le pubblicazioni mirate per soddisfare i clienti rafforza la forza e la scalabilità del prodotto nel suo insieme e lascia il business sicuro di avere la capacità di crescere rapidamente in un mercato selvaggio e volatile. Alcuni svantaggi sono la maggiore complessità dell'applicazione e del prodotto stesso, e le considerazioni sull'aumento dei tempi di sviluppo iniziale e sui costi più elevati associati a questo.

Considerazioni sul cliente

I clienti possono sentirsi sicuri che i loro bisogni siano soddisfatti attraverso il prodotto senza una significativa personalizzazione e che le loro richieste e modifiche possano essere rapidamente soddisfatte.

Dopo aver detto che l'eccessiva flessibilità è la causa di molte complicazioni eccessive nel software, puoi immaginare un framework così flessibile da permetterti di offrire una flessibilità infinita ai tuoi clienti?

Detto questo, suggerirei di scrivere un DSL, piuttosto che usare XML, per un motore di regole di personalizzazione.

Puoi utilizzare ANTLR per creare una DSL da zero oppure scrivi un DSL su Boo , il che significa che non devi prendere decisioni banali come la formattazione del codice e la precedenza degli operatori, devi solo lavorare con ciò che è unico al tuo problema di dominio.

Questo dovrebbe semplificare drasticamente il tuo attuale motore di regole e anche essere più estensibile in futuro. Come ulteriore vantaggio, se lo fai bene, sarà più facile da leggere per l'utente finale, in modo che possano visualizzare le proprie regole di personalizzazione e confermare la loro correttezza.

7500 righe di codice (XML) sono allarmanti - penso che devi chiederti quanti benefici traggono i tuoi utenti dalla personalizzazione e quanto costa a fornirli. Personalmente inizierei cercando di ridurre il più possibile la personalizzazione.

Successivamente sposterei qualsiasi personalizzazione rimasta in un database come dati molto semplici (qualcosa di simile alle coppie di valori nomi ma per ciascun cliente e forse consentendo un campo tipo e un numero sequenza). Fornire una semplice interfaccia web semplice e controllare che tutti i valori inseriti siano validi. L'obiettivo è di renderlo così facile da cambiare che alla fine i tuoi clienti saranno in grado di farlo. È inoltre possibile inserire le impostazioni di default del sistema in questa struttura in modo da poter modificare il comportamento predefinito tramite il database.

create table CustomerSettings( 
   customerId         int,
   type               varchar(20),
   name               varchar(20),
   value              varchar(20),
   sequence           int null
);

insert CustomerSettings ( 0, "FORMAT", "emp_no", "^[0-9]+$" ); // default

insert CustomerSettings ( 123, "MENU","main_menu","hire people",1

insert CustomerSettings ( 123, "MENU","main_menu","fire people",2

insert CustomerSettings ( 123, "HIDE","salary",null, null );

insert CustomerSettings ( 123, "FORMAT","emp_no","^[A_E][0-9]+$", null );

etc, etc

L'app web caricherà prima tutti i valori per un cliente o, se non è presente alcun valore, caricherà il valore predefinito. Un nuovo cliente verrebbe quindi eseguito semplicemente usando i valori predefiniti. Puoi aggiungere le impostazioni al volo finché il cliente non è felice.

I dati per cliente dovrebbero, si spera, essere molto più piccoli. Utilizzare i valori predefiniti laddove possibile.

Mike

PS per favore perdona la formattazione, non sono riuscito a capire come inserire il codice in un post.