Come creare moduli Web flessibili in ASP.NET

Question

Sto usando asp.net e ho bisogno di creare un'applicazione in cui possiamo facilmente creare moduli senza ricreare il database, e preferibilmente senza modificare crea/leggi/aggiorna/cancella interrogazioni. L'obiettivo è quello di consentire ai clienti di creare i propri moduli con elenchi a discesa, caselle di testo, caselle di controllo, anche una relazione molti-a-uno con un altro semplice modulo (che lo sta allungando). L'utente non deve essere in grado di creare i moduli stessi, ma non voglio aggiungere tabelle, campi, query, pagine Web, ecc. Ogni volta che viene richiesto/modificato un nuovo modulo.

2 domande: 1) Come si struttura un database flessibile per eseguire questa operazione (in SQL Server)? Posso pensare a due modi: a) Creare una tabella per ogni tipo di dati (int, varchar (x), smalldatetime, bit, ecc.). Questo sarebbe molto difficile da creare le domande adeguate. b) Creare la tabella del modulo con molti campi aggiuntivi e vari tipi di dati nel caso in cui l'utente abbia bisogno di 5 interi o 5 campi data. Questo sembra il più semplice, ma è probabilmente un uso piuttosto inefficiente dello spazio.

2) Come si creano i moduli? Ho pensato di creare un foglio xml che avesse le convalide, il tipo di dati, il controllo da visualizzare, ecc. Come elenco. Quindi analizzerei l'xml per creare il modulo al volo. Probabilmente usando css per fare il layout (che dovrebbe essere manuale, che è ok).

C'è un modo migliore/migliore? C'è qualcosa là fuori che potrei guardare per avere idee? Ogni aiuto è molto apprezzato.

Answer 1

Sembra un potenziale candidato per una soluzione InfoPath. A prima vista, farà la maggior parte di tutto ciò che stai chiedendo.

Questo articolo fornisce una breve panoramica sulla creazione di un modulo di InfoPath basato su un'origine dati SQL.

http://office.microsoft.com/en-us/infopath-help/design-a-form-template-based-on-a-microsoft-sql-server-database-HP010086639.aspx

ho costruito una soluzione completamente personalizzata come si sta descrivendo, e se mai fatto di nuovo io probabilmente optare per 1) un prodotto di terze parti o 2) meno funzionalità. Puoi dedicare il 90% del tuo tempo a lavorare sul 10% del set di funzionalità.

MODIFICA: rileggi le tue domande ed ecco un feedback aggiuntivo.

1 - struttura dati flessibile: Un paio di cose da tenere a mente sono le prestazioni e la capacità di scrivere rapporti contro i dati. Più è generica la struttura dei dati, più sarà difficile raggiungerli (di nuovo, parlando per esperienza).

Contrariamente alle prestazioni e alla disponibilità del report, Microsoft SharePoint utilizza frammenti/documenti XML in tabelle generiche per la massima flessibilità. Non posso discutere con le caratteristiche di SharePoint, quindi questo ha fatto il lavoro e semplifica enormemente la struttura dei dati. XML funzionerà correttamente se fatto correttamente, ma molte persone troveranno più difficile scrivere query su XML. Anche se XML è un "cittadino di prima classe" per SQL Server, può avere o meno una struttura di tabella ottimizzata.

2 - Forme: Ho implementato moduli personalizzati utilizzando XML trasformato da XSLT. XML è spesso una buona scelta per la memorizzazione della struttura del modulo; XSLT è un mostro a sé, ma è è molto potente. Per quello che vale, InfoPath memorizza la struttura del modulo come XML.

Ho anche implementato moduli dinamici utilizzando i controlli personalizzati in .Net. Questo è un approccio molto orientato agli oggetti, ma (a seconda della complessità dell'interfaccia utente) può richiedere una quantità significativa di codice.

Infine, (sempre utilizzando SharePoint come esempio), Microsoft ha implementato in XML SharePoint liste di elenchi/formule orribilmente complicate. La complessità ha vanificato molti dei vantaggi. In altre parole, se segui il percorso XML, rendi le tue strutture pulite e semplici o avrai un incubo di manutenzione a portata di mano.

EDIT # 2: In riferimento alla domanda di Scott di seguito, ecco una struttura di dati di alto livello che eviterà i dati duplicati e non si basa su XML per la maggior parte della definizione di modulo.

Avvertenza: ho appena messo insieme questo disegno in SQL Management Studio ... ho trascorso solo 10 minuti; lo sviluppo di un sistema di moduli flessibile non è un compito banale, quindi questa è una semplificazione eccessiva. Non affronta la memorizzazione dei dati inseriti dall'utente, solo la definizione del modulo.

Le tabelle:

Form - top-level tavolo forma che contiene (come ci si indovina) la raccolta dei campi che compongono il modulo.

Campo: campi generici che possono essere riutilizzati attraverso i moduli. Ad esempio, non vuoi 50 diversi campi "Cognome" per 50 moduli diversi. Nota la colonna "DataTypeId". È possibile memorizzare qualsiasi tipo desiderato in questa colonna, ad esempio "numero", testo libero ", anche un valore che indica che l'utente deve scegliere da un elenco.

FormField - consente a un modulo di contenere 0-molti campi nel suo definizione Si potrebbe anche estendere questa tabella per indicare che l'utente può AGGIUNGERE il maggior numero di questo campo.

Vincolo: in pratica una tabella di ricerca che definisce un tipo di vincolo (forse è la lunghezza massima, le occorrenze massime, richiesto, ecc.)

FormFieldConstraint - associa un vincolo a una particolare istanza di un campo modulo.Questa tabella combina un modulo specifico con un campo specifico con un vincolo specifico. n; questo potenzialmente sarebbe un buon uso per XML per memorizzare le specifiche del vincolo.

In sostanza, suggerisco di creare un database normalizzato con pochi o nessun valore nullo e nessun dato duplicato. Una struttura come ho descritto ti porterebbe sulla strada per raggiungere quell'obiettivo.

Answer 2

Penso che se sono necessari moduli veramente dinamici salvati in un database, è necessario creare una sorta di tabella di dati "dizionario".

Per esempio ...

UserForms 
--------- 
FormID 
FieldName 
FieldValue 

FormID ricollega alla forma genitore (in modo da poter aggregare tutti i campi per una forma. FieldName è il nome del campo di testo inserito da. FieldValue è il valore immesso/selezionato per il campo.

Ovviamente questa non è una soluzione perfetta. si potrebbe avere problemi a digitare i dati in modo dinamico, ma lascio l'attuazione di tale fino a voi.

in ogni modo, speriamo che questo dà da qualche parte per iniziare a pensare su come ti piacerebbe realizzare cose. In bocca al lupo!

P.S. Ho trovato l'utilizzo di webform con .NET come un dolore totale durante la generazione dinamica di moduli. Nei casi in cui ho dovuto farlo, l'ho abbandonato quasi completamente e ho usato elementi HTML nativi. Quindi rewired il mio modulo utilizzando i valori necessari da Request. Probabilmente non è una soluzione perfetta, ma ha funzionato al meglio per me.

Answer 3

Abbiamo creato un sistema di moduli come quello che stai descrivendo con uno schema molto simile a quello alla fine del post di Tim. È stato piuttosto complicato, e abbiamo dovuto lottare con i controlli standard di WebForms come DetailsView e GridView per renderli in grado di eseguire operazioni CRUD su gruppi di risposte. Sono utilizzati per legare direttamente alle proprietà su un oggetto e li stiamo costringendo a cercare prima un ID campo in un dizionario. A loro non piace Si consiglia di prendere in considerazione l'utilizzo di MVC.

Una domanda complicata è come memorizzare le risposte. Abbiamo finito per utilizzare una tabella con chiave FieldId, InstanceId (ad esempio, se 10 persone compilano il modulo, ci sono 10 istanze) e RowNumber (perché supportiamo moduli a più righe per cose come la cronologia dell'occupazione). Invece di farlo in questo modo, ti consiglio di rendere il tuo AnswerRow un concetto di prima classe con la sua tabella legata a un'Istanza e di avere le risposte collegate a AnswerRow e Field.

Per supportare diversi tipi di valore, abbiamo dovuto creare più campi di risposta sulla nostra tabella di risposta (AnswerChar, AnswerDate, AnswerInt, AnswerDecimal). Ciascuna di queste mappe ad uno o più tipi di campo (data, ora, numero, ecc.). Ogni tipo di campo ha la propria logica per rappresentare il valore nell'interfaccia utente e inserisce il valore nella proprietà appropriata sui nostri oggetti risposta.

Tutto sommato, è stato un sacco di lavoro. Ne vale la pena per noi, dato che questo è il punto cruciale del prodotto, ma vorrete sicuramente tenere a mente i costi prima di intraprendere un progetto come questo.