Opciones para manejar un formulario de datos que cambia frecuentemente

Question

¿Cuáles son algunos diseños posibles para manejar formularios de datos que cambian con frecuencia?

Tengo una aplicación web CRUD básica donde el formulario de entrada de datos principal cambia anualmente. Por lo tanto, cada registro debe vincularse a una versión específica del formulario. Este requisito es algo nuevo, por lo que la aplicación existente no se creó teniendo esto en cuenta.

Estoy buscando diferentes formas de manejar esto, con la esperanza de evitar futuras deudas técnicas. Aquí hay algunas opciones que he encontrado:

• Cree un nuevo objeto, interfaz de usuario y conjunto de tablas para cada versión. Este es obviamente el enfoque más ingenuo.
• Siga agregando todos los campos al mismo objeto y las tablas de base de datos, pero muéstrelos u ocultelos según la versión del formulario. Esto se convertirá en un desastre después de algunos cambios.
• Construya definiciones de formularios, luego construya la interfaz de usuario dinámicamente y almacene los datos como un diccionario (ej. JSON/XML o una base de datos orientada a documentos). Creo que esto será demasiado complejo para el alcance de esta aplicación, especialmente para la IU.

¿Qué otras posibilidades hay? ¿Alguien tiene experiencia haciendo esto? Estoy buscando algunos patrones de diseño para ayudar a lidiar con la complejidad.

Answer 1

Para esta aplicación en particular, decidimos tratar el problema como si hubiera un formulario que creciera continuamente. Debido a la naturaleza de la forma, esto parecía más natural que una separación más explícita. Tendremos un mapeo del campo año-> para partes de la aplicación que necesitan saber qué datos corresponden a cada año.

Para la interfaz de usuario, crearemos una página nueva para cada año. La creación de formas dinámicas es demasiado compleja en esta situación.

Answer 2

Primero, hablaré con sus soluciones arriba y luego daré mi respuesta.

• Creación de una nueva tabla para cada versión va a requerir nueva programación cada año desde que se no ser capaz de unirse de forma dinámica a la nueva tabla e incluir las nuevas columnas fácilmente. Eso parece bastante obvio y realmente hace que esta sea una mala elección.
• Los problemas que mencionó al agregar las columnas al mismo formulario son
  correctos. Además, cualquiera que sea la base de datos que use tiene un máximo de cuántas columnas puede manejar y cuántos bytes puede tener en una fila. Eso podría convertirse en otra preocupación.
• La tercera opción creo que es la más cercana a lo que desea. Me gustaría no almacenar los datos de la nueva columna en un JSON/XML a menos que sea para la duplicación para aumentar la velocidad. Creo que esta es la mejor opción
• La única opción que no ha mencionado se almacenan todos los datos en el campo 1 base de datos y el uso de XML a de análisis. Esta opción lo haría difícil de consultar y escribir informes en contra.

Si tuviera que hacer esto:

1. La primera tabla tendría el ID columnas (sin semillas), Nombre, InputType, CreateDate, ExpirationDate y CssClass. I lo llamaría tbInputs.
2. La segunda tabla tendría la tienen 5 columnas, ID, Input_ID (con FK a tbInputs.ID), entrada_id (con FK a la tabla principal/Original) valor, y CreateDate. El FK a la tabla principal/original le permitiría para encontrar qué elementos estaban adjuntos a qué entrada de formulario. Llamaría a esto tabla tbInputValues.
3. Si no planifica tener esa tabla base, entonces Usaría una tabla simple que rastrea la fecha de creación, ID del creador, y form_id.
4. Una vez que los tenga, solo tendrá que crear un formulario dinámico que retire todas las entradas que están activas actualmente y las muestre. Pondría todos los controles dinámicos dentro de algún tipo de contenedor, como <div>, ya que le permitirá recorrerlos sin saber el nombre de cada elemento. Luego inserte en tbInputValues ​​la ID de la entrada y su valor.
5. Cree un formulario para agregar o eliminar una entrada . Esto significa que usted no tendrá mucho o ningún mantenimiento que hacer todos los años .

Creo que esta solución puede no parecer la más elocuente, pero si se ejecuta correctamente, creo que es la solución más flexible que requiere la menor cantidad de deuda técnica.

Answer 3

Creo que el tercer enfoque (XML) es el más flexible. Una estructura XML simple se genera muy rápido y puede ser fácilmente versionada y validada contra un XSD.

Tendría una tabla que contiene el XML en una columna y el año/versión a la que se aplica este xml.

Generar código de IU basado en el esquema es básicamente una mala idea. Si no requiere una validación extensa, puede optar por una tabla editable simple.

Si necesita un formulario personalizado cada año, lo vería como una especie de garantía de trabajo :-) Sin embargo, es importante hacer que el mecanismo de control de versiones y la extensión sean transparentes y explícitos.