Cómo crear formularios web flexibles en ASP.NET

Question

Estoy usando asp.net y necesito crear una aplicación donde podamos crear formularios fácilmente sin volver a crear la base de datos, y preferiblemente sin cambiar la creación/lectura/actualización/eliminación consultas. El objetivo es permitir a los clientes crear sus propios formularios con listas desplegables, cuadros de texto, casillas de verificación, incluso la relación de muchos a uno con otra forma simple (eso es estirarla). El usuario no tiene que poder crear los formularios por sí mismo, pero no quiero agregar tablas, campos, consultas, página web, etc. cada vez que se solicita/modifica un nuevo formulario.

2 preguntas: 1) ¿Cómo estructurar una base de datos flexible para hacer esto (en SQL Server)? Puedo pensar en dos formas: a) Crear una tabla para cada tipo de datos (int, varchar (x), smalldatetime, bit, etc.). Esto sería muy difícil de crear las consultas adecuadas. b) Cree la tabla de formularios con muchos campos adicionales y varios tipos de datos en caso de que el usuario necesite 5 enteros o 5 campos de fecha. Parece el uso más fácil, pero probablemente bastante ineficiente, del espacio.

2) ¿Cómo construyo los formularios? Pensé en crear una hoja xml que tuviera las validaciones, el tipo de datos, el control para mostrar, etc. como una lista. Luego analizaría el xml para construir el formulario sobre la marcha. Probablemente usar CSS para hacer el diseño (que debería ser manual, lo cual está bien).

¿Existe una mejor/mejor manera? ¿Hay algo por ahí que pueda mirar para obtener ideas? Cualquier ayuda es muy apreciada.

Answer 1

Parece un candidato potencial para una solución de InfoPath. A primera vista, hará la mayoría/todo lo que está pidiendo.

Este artículo ofrece una breve descripción general de la creación de un formulario de InfoPath que se basa en una fuente de datos SQL.

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

he construido una solución completamente personalizada como usted está describiendo, y si alguna vez lo hizo de nuevo, probablemente optar por cualquiera de 1) un producto de terceros o 2) menos funcionalidad. Puede dedicar el 90% de su tiempo a trabajar en un 10% del conjunto de funciones.

EDIT: vuelva a leer sus preguntas y aquí hay comentarios adicionales.

1 - Estructura de datos flexible: Un par de cosas a tener en cuenta son el rendimiento y la capacidad de escribir informes con los datos. Cuanto más genérica sea la estructura de datos, más difícil será lograrlo (nuevamente, hablando desde la experiencia).

De forma contraria al rendimiento y la preparación de informes, Microsoft SharePoint usa fragmentos/documentos XML en tablas genéricas para una máxima flexibilidad. No puedo discutir las características de SharePoint, por lo que hace el trabajo y simplifica enormemente la estructura de datos. XML funcionará bien cuando se realice correctamente, pero a la mayoría de las personas les resultará más difícil escribir consultas en XML. Aunque XML es un "ciudadano de primera clase" para SQL Server, puede funcionar o no tan bien como una estructura de tabla optimizada.

2 - Formas: Implementé formularios personalizados utilizando XML transformado por XSLT. XML es a menudo una buena opción para almacenar la estructura del formulario; XSLT es un monstruo en sí mismo, pero es muy potente. Por lo que vale, InfoPath almacena su estructura de formulario como XML.

También he implementado formularios dinámicos usando controles personalizados en .Net. Este es un enfoque orientado a objetos, pero (dependiendo de la complejidad de la interfaz de usuario) puede requerir una cantidad significativa de código.

Por último (otra vez usando SharePoint como ejemplo), Microsoft implementó definiciones extremadamente complicadas de listas/formularios XML en SharePoint 2007. La complejidad derrota a muchos de los beneficios. En otras palabras, si va por la ruta XML, haga que sus estructuras sean simples y limpias o tendrá una pesadilla de mantenimiento en sus manos.

EDIT # 2: En referencia a la pregunta de Scott a continuación, aquí hay una estructura de datos de alto nivel que evitará la duplicación de datos y no confía en XML para la mayoría de la definición de formulario.

Advertencia: Acabo de poner este diseño en SQL Management Studio ... Solo pasé 10 minutos en él; desarrollar un sistema de formulario flexible no es una tarea trivial, por lo que se trata de una simplificación excesiva. No aborda el almacenamiento de los datos ingresados ​​por el usuario, solo la definición del formulario.

Las tablas:

Form - Clasificación de la forma de nivel superior que contiene (como era de adivinar) el conjunto de campos que componen el formulario.

Campo: campos genéricos que pueden reutilizarse en todos los formularios. Por ejemplo, no desea 50 campos diferentes de "Apellido" para 50 formularios diferentes. Tenga en cuenta la columna "DataTypeId". Puede almacenar cualquier tipo que desee en esta columna, como "número", texto libre ", incluso un valor que indique que el usuario debe elegir de una lista.

FormField - permite que un formulario contenga 0-muchos campos en su definición. Incluso podría extender esta tabla para indicar que el usuario puede AGREGAR tantos de este campo como lo necesite.

Restricción: básicamente una tabla de búsqueda que define un tipo de restricción (tal vez su longitud máxima, ocurrencias máximas, requeridas, etc.)

FormFieldConstraint: relaciona una restricción con una instancia particular de un campo de formulario. Esta tabla combina un formulario específico con un campo específico con una restricción específica. Tenga en cuenta la columna de metadatos norte; esto podría ser un buen uso para XML para almacenar los detalles de la restricción.

Esencialmente, sugiero construir una base de datos normalizada con pocos o ningún valor nulo y sin datos duplicados. Una estructura como la que describí te llevaría al camino hacia ese objetivo.

Answer 2

Creo que si necesita formularios verdaderamente dinámicos guardados en una base de datos, tendría que crear una especie de tabla de datos "del diccionario".

Por ejemplo ...

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

FormID relaciona de nuevo a la forma original (para que pueda agregar todos los campos de un formulario. NombreCampo es el nombre del campo de texto introducido. ValorDelCampo es la valor introducido/seleccionado para ese campo.

Obviamente, esto no es una solución perfecta. usted podría tener problemas a escribir los datos de forma dinámica, pero salir de la aplicación de esa depende de usted.

de todas formas, espero que esto da Estás en algún lugar para comenzar a pensar acerca de cómo te gustaría lograr cosas. ¡Buena suerte!

P.S. He encontrado que usar formularios web con .NET es un dolor total al hacer la generación dinámica de formularios. En las instancias en que tuve que hacerlo, lo descarté casi por completo y usé elementos HTML nativos. Luego volvió a cablear mi formulario usando los valores necesarios desde Request. Probablemente tampoco sea la solución perfecta, pero funcionó mejor para mí.

Answer 3

Creamos un sistema de formularios como el que está describiendo con un esquema muy similar al que está al final de la publicación de Tim. Ha sido bastante complicado, y realmente tuvimos que luchar con los controles estándar de WebForms como DetailsView y GridView para que puedan realizar operaciones CRUD en grupos de respuestas. Están acostumbrados a enlazar directamente a las propiedades de un objeto, y los estamos forzando a buscar primero una identificación de campo en un diccionario. No les gusta. Es posible que desee considerar el uso de MVC.

Una pregunta difícil es cómo almacenar las respuestas. Terminamos usando una tabla que está marcada en FieldId, InstanceId (por ejemplo, si 10 personas están llenando su formulario, hay 10 instancias) y RowNumber (porque admitimos formularios de varias filas para cosas como el historial de empleo). En lugar de hacerlo de esta manera, recomendaría hacer de su AnswerRow un concepto de primera clase con su propia tabla vinculada a una instancia, y tener las respuestas vinculadas a AnswerRow y Field.

Para admitir diferentes tipos de valores, tuvimos que crear múltiples campos de respuesta en nuestra tabla de respuestas (AnswerChar, AnswerDate, AnswerInt, AnswerDecimal). Cada uno de estos mapas a uno o más tipos de campo (fecha, hora, número, etc.). Cada tipo de campo tiene su propia lógica para representar el valor en la interfaz de usuario, y poner el valor en la propiedad adecuada en nuestros objetos de respuesta.

En general, ha sido mucho trabajo. Vale la pena para nosotros, ya que este es el quid del producto, pero definitivamente querrás tener en cuenta el costo antes de embarcarte en un proyecto como este.