¿Cómo maneja las personalizaciones de formularios para diferentes clientes?

Question

En nuestra aplicación, a veces tenemos que hacer modificaciones menores de GUI para diferentes clientes:

• Un cliente tiene un campo de entrada que los demás no tienen.
• Otro cliente tiene todos los campos predeterminados, pero uno de los campos de entrada opcionales es obligatorio.
• Un tercer cliente tiene los campos predeterminados, pero un campo tiene su título cambiado
• Un cuarto cliente tiene varios campos de entrada nuevos y un campo de entrada multilínea existente debe cambiarse a un campo de entrada de una sola línea (para dejar espacio para los nuevos campos)
• ...

(Nota: aunque estos ejemplos pueden parecer incómodos, es lo que nuestros clientes pidieron)

¿Cómo manejas estos casos?

• En general
• En Java / Swing

Actualmente diseñamos el formulario de la manera más común. En el tiempo de ejecución, realizamos ajustes como ocultar, redimensionar o reposicionar campos. En la validación de entrada, validamos los contenidos según el cliente activo.

Answer 1

Este problema tiene tres aspectos: diseño de formulario, almacenamiento de base de datos y lógica empresarial configurable.

Diseño de formulario controlado por la configuración

Se puede lograr un enfoque flexible para el diseño del formulario moviendo el diseño a un archivo descriptor. Tres kits de herramientas GUI que admiten esto son QT, WPF y XUL. Sin embargo, AFAIK Swing no admite directamente esta capacidad. QT Jambi le permite usar QT en Java como una alternativa a Swing y QT 4.5 estará disponible con licencia LGPL. Esta no es una solución puramente de Java, pero puede ser una posibilidad si esto y la reescritura del código de la interfaz de usuario es aceptable.

La ventaja del diseño de formulario basado en la configuración es que las personalizaciones se pueden hacer sin tener que mantener una compilación separada para cada cliente, por lo que incluso si tiene una base de código titular, es posible que desee examinar si hay un caso de negocios adoptar un kit de herramientas de este tipo frente a mantener múltiples compilaciones específicas del cliente. Sin embargo, para un lenguaje compilado, es posible que deba configurar algún tipo de marco de complemento para el código de formulario generado.

Almacenamiento de base de datos configurable

Esto es más complejo. Puede hacer esto de tres maneras, que tienen sus ventajas y desventajas.

1. El primer enfoque es tener una serie de campos de 'usuario' en la tabla, como 'Usuario1', 'Usuario2', etc. Los campos configurados en los formularios se pueden asignar a estos campos, y un usuario genérico El mapeo de campo no debería ser difícil de implementar. Este es el más eficiente desde una perspectiva de consulta de base de datos, pero adolece de la limitación de un número finito de campos posibles. Si tiene los campos 'Usuario1' a 'Usuario20' solo puede admitir 20 atributos definidos por el usuario. Además, deberán ser varchars genéricos amplios y agradables, por lo que no obtendrá ningún tipo de seguridad de la base de datos.

2. El segundo enfoque es tener una tabla de atributos colgando de la entidad. Esto no le da seguridad de escritura, pero le permite tener tantos atributos como desee. Construir un controlador genérico para esto también es bastante factible, pero el rendimiento de la consulta se verá afectado a medida que realice varias uniones en la tabla de atributos.

3. Persiste los campos definidos por el usuario en un blob XML. Esto tiene poco que recomendar, ya que dificulta el acceso a los datos a través de la base de datos. Sin embargo, lo he visto hecho.

Lógica empresarial configurable

Este es un tema mucho más espinoso. Sin agregar código personalizado y cambiar su compilación, tiene algunas opciones para hacer reglas de negocio configurables: motores de reglas, lenguajes de scripting o un conjunto de características estándar de encendido / apagado como campos obligatorios.

1. Motores de reglas: realmente tiene que diseñar su aplicación desde cero para usarlos, y tienen sus propias limitaciones y debilidades. ILOG, el titular en este campo, también es bastante caro. Para Java, JESS podría ser una opción.

2. Lenguaje de script incorporado: al agregar un intérprete para Jython, Groovy o algún otro lenguaje interpretado compatible con JVM, puede escribir complementos para el sistema sin tener que emitir una nueva compilación. Todavía se incurrirá en alguna carga de trabajo de prueba, pero esto podría ser una ganancia de mantenimiento en general.

3. Configuración de encendido / apagado para funciones. Esta es la opción menos flexible, pero es relativamente simple y agrega relativamente poco en cuanto a dependencias externas y costos de licencia. También puede ser su única opción si está tratando de adaptar la configuración a algo que comenzó como una aplicación a medida.

Ninguna de las anteriores

Si la respuesta es 'Ninguna de las anteriores', probablemente esté atrapado con compilaciones personalizadas. En ese caso, cree una arquitectura de complemento para los formularios para que al menos pueda aislar los elementos específicos del cliente en un módulo separado.

Answer 2

Hay un par de formas diferentes de hacerlo. Sin embargo, depende mucho de la situación.

1. En lugar de agregar una lógica de cliente diferente en la misma pantalla, tenga una pantalla diferente por cliente con una predeterminada que todos usen.

2. Compilaciones personalizadas o sucursales de clientes. Aunque esto puede ser bastante complicado.

3. Haz exactamente lo que has hecho e integra la lógica específica del cliente en las pantallas.

4. Use algún tipo de motor de reglas para manejar su interfaz.

Answer 3

Puedo pensar en 4 enfoques:

1. No lo hagas. Sí, sé que es demasiado tarde ahora, pero si puedes salirte con la tuya, siempre vende un producto estándar.

Si eso no es posible ...

2. Cree una matriz de características, donde cada cliente puede definir sus propios requisitos marcando casillas (Campo deshabilitado, Presente obligatorio, Presente opcional, etc.). Limita la forma en que puede presentar su información en la interfaz de usuario: tiende a un diseño más simple, pero es escalable y flexible.
3. Tenga una página personalizada por cliente, donde cada página se respalde a sí misma en términos de lógica y validación comercial. Quizás pueda escapar con 3 o 4 variantes que se ofrecen a cada cliente.
4. Ramificación. Si hace esto, asegúrese de que el cliente paga porque es una PITA costosa.

Answer 4

No estoy seguro de qué tipo de aplicación es esta, pero cuando recibimos solicitudes de características en conflicto, generalmente ramificamos la versión de cada cliente e incluimos solo el código relevante en cada rama.

¿Está utilizando algún tipo de control de código / sistema de versiones? SVN es lo que usamos, y le permite actualizar cada rama a medida que realiza cambios en el código principal, por lo que el código nunca está desactualizado.

Answer 5

Haría algo similar a la pantalla de creación de FORMULARIOS dentro de MS Access, permitiría al cliente agregar / eliminar / modificar y establecer entradas por su cuenta. También les permitiría establecer qué campos son obligatorios y cuáles no. Significaría más trabajo en la parte delantera para usted, pero menos en la parte posterior.

Answer 6

Sugeriría usar algún tipo de sistema de complemento. Para cada cliente, solo cree un complemento que modifique la interfaz de usuario de su aplicación y cárguelo al inicio. No soy un programador de Java, así que me temo que no puedo publicar ningún fragmento de código específico.