Generación de IU de DB: ¿bueno, malo y feo?

Question

He leído una declaración en algún lugar que la generación de la interfaz de usuario automáticamente desde el diseño de la base de datos (u objetos comerciales, o cualquier otra capa de negocios) es una mala idea. También puedo imaginar algunos buenos desafíos que uno debería enfrentar para hacer algo como esto.

Sin embargo, no he visto (ni he podido encontrar) ningún ejemplo de gente que lo haya intentado. Por lo tanto, me pregunto: ¿es realmente tan malo? Definitivamente no es fácil, pero ¿se puede hacer con cualquier medida de éxito? ¿Cuáles son los principales obstáculos? Sería grandioso ver algunos ejemplos de éxitos y fracasos. Para aclarar: con "generar IU automáticamente" quiero decir que todos los formularios con todos sus controles se generan completamente automáticamente (en tiempo de ejecución o tiempo de compilación), quizás basándose en algunos consejos en metadatos sobre cómo se deben representar los datos. Esto está en contraste con el diseño de formularios a mano (como la mayoría de las personas).

Agregado: encontrado this somewhat related question

Agregado 2: OK, parece que una manera esto puede obtener resultados muy justos es suficiente si los metadatos relacionados con la presentación está disponible. Para este enfoque, ¿cuánto sería "suficiente" y sería menos trabajo que diseñar el formulario manualmente? ¿También proporciona una mayor flexibilidad para cambios futuros?

Answer 1

Teníamos un proyecto que generaría las tablas de la base de datos/proc almacenado así como la UI de las clases de negocios. Fue hecho en .NET y usamos muchos Atributos Personalizados en las clases y propiedades para que se comportara como nosotros quisiéramos. Sin embargo, funcionó muy bien y si logras seguir tu diseño puedes crear personalizaciones de tu software muy fácilmente. También tuvimos una forma de poner controles de usuario "personalizados" para algunos casos muy excepcionales.

En general, funcionó bien para nosotros. Desafortunadamente es un producto bancario vendido y no hay una fuente disponible.

Answer 2

hey esto no es difícil de lograr en absoluto y no es una mala idea en absoluto. todo depende de las necesidades de su proyecto. muchos productos de software (no importa los proyectos sino los productos) dependen de este modelo, por lo que no tienen que volver a escribir su lógica de código/ui para las diferentes necesidades del cliente. los clientes pueden personalizar su interfaz de usuario de la manera que desean utilizando un formulario de diseño en el sistema de administración

he utilizado xml para preservar los metadatos para este tipo de cosas.algunos de los atributos que he salvado para cada campo fueron:

1. friendlyname (título de la etiqueta)
2. haspredefinedvalues ​​(sí para dejar desplegable/verificación de múltiples lista del cuadro)
3. selección múltiple (si es sí, entonces casilla de verificación lista, si no, entonces la lista desplegable)
4. tipo de datos
5. maxlength
6. requerido
7. MINVALUE
8. maxvalue
9. RegularExpression
10. habilitado (para mostrar o no mostrar)
11. SortKey (orden en el formulario de la web)

respecto posicionamiento - No me importaba mucho y simplemente genero table tr td etiquetas 1 debajo de la otra; sin embargo, si desea implementar esto también, puede tener 1 atributo más llamado CssClass donde puede definir propiedades específicas de ui (apariencia, posicionamiento, etc.) aquí

ACTUALIZACIÓN: también tenga en cuenta que muchos productos de comercio electrónico siguen este tipo de interfaz de usuario dinámica cuando desea ingresar información del producto, ya que sus clientes pueden vender todo bajo el sol de muebles a juguetes sexuales ;-) en lugar de reescribir su código para cada diferentes industrias simplemente dejan que sus clientes ingresen metadatos para los atributos del producto a través de un formulario de administración :-)

también les recomiendo que miren Entity-attribute-value model - tiene sus propios pros y contras, pero creo que se puede usar bastante bien con tus requerimientos

Answer 3

está bien para algo pequeño donde todo lo que necesita es un método utilitario para obtener los datos en.

de algo parecido a una aplicación real sin embargo, es una idea terrible. Lo que hace que una buena IU sea el factor de humanización, los bits que modificas para garantizar que esta máquina reaccione bien al tacto de una persona.

simplemente no puede obtener eso cuando su interfaz se genera mecánicamente ... bueno, tal vez con algo que se acerca a AI. :)

editar - aclarar: la IU generada a partir de código/db está bien como punto de partida, es solo un punto final de basura.

Answer 4

En mi opinión hay algunas cosas que debe considerar:

1. necesita el cliente en función de personalizar su interfaz de usuario?
2. ¿Hay muchos atributos o elementos diferentes?
3. ¿Vale la pena el esfuerzo de crear un "motor de renderizado" de este tipo?

De acuerdo, creo que es bastante obvio por qué deberías pensar en esto. Realmente depende de su proyecto si ese tipo de modelo tiene sentido ... Si desea crear muchos formularios que puedan personalizarse en tiempo de ejecución, entonces este modelo podría ser muy útil. Además, si necesita hacer muchas herramientas más pequeñas y usa esto como una especie de "motor", entonces este esfuerzo podría valer la pena, ya que puede ahorrar mucho tiempo. Con ese tipo de "motor de renderizado", puede agregar reportes de error automáticamente, verificar los valores o agregar otras cosas que siempre se desarrollan con el mismo patrón. Pero si tiene demasiadas cosas, elementos o atributos, entonces el rendimiento puede disminuir rápidamente. Otra cosa que se vuelve interesante en proyectos más grandes es que los cambios que tienen que ocurrir en cada formulario solo tienen que hacerse en el motor, no en cada formulario. Esto podría ahorrar MUCHO tiempo si hay un error en la aplicación finalizada.

En nuestra compañía utilizamos un modelo similar para un generador de interfaz entre cash-software (en este momento no puedo recordar la palabra correcta para ello ...) y nuestra aplicación, solo que no crea una UI, sino una salida archivo para una de las aplicaciones. Usamos XML para definir la estructura y cómo se deben convertir los valores, etc.

Answer 5

Diría que en la mayoría de los casos los datos no son adecuados para la generación de IU. Es por eso que casi siempre pone una capa de lógica entre ellos para interpretar la información de DB para el usuario. Otra cosa es que cuando generes la interfaz de usuario desde DB terminarás mostrando el funcionamiento interno del sistema, algo que normalmente no quieres hacer.

Pero depende de dónde provenga la base de datos. Si fue creado para reflejar exactamente cuáles son los objetivos del usuario del sistema. Si el modelo mental de los usuarios de lo que la aplicación debería ayudarles se almacena en el DB. Entonces podría funcionar. Pero entonces usted tiene para comenzar en el extremo del usuario. Si no, te sugiero que no vayas de esa manera.

Answer 6

¿Puede ver su problema desde la perspectiva de la arquitectura de la aplicación? Te veo como otro terrorista de base de datos, tratando de resolver todo escribiendo procedimientos almacenados. ¿Por qué tener UI en absoluto? Intenta hacerlo en el script DB. En efecto, de ese enfoque: ¿en qué sistema compuesto terminarás? Cuando el sistema atiende a empresas diferentes, intente la modularización, descubra componentes selectivamente, restrinja el uso compartido de referencias. La IU debe ser reemplazable, independiente de la capa comercial. Cuando se almacenan tantos datos en DB, existe una gran dependencia de la IU, el sistema se convierte en monolito. ¿Cómo implementa el patrón MVVM en el escenario cuando se genera la IU? Los diseñadores como Blend contienen muchas características que no pueden ser reemplazadas por la mayoría de los generadores de UI futuristas, a menos que su plataforma de desarrollo sea solo Notepad.