Consejos de modelado de JavaBeans para optimizar el desarrollo de tus aplicaciones WebDynpro

Antecedentes

Antes de adentrarse en los detalles de esta publicación, responda varias preguntas por sí mismo.

1. ¿Te sientes cómodo con los nodos de valor?
2. No pases por alto la pregunta [1]. Realmente, intenta contar los clics necesarios para vincular un modelo RFC adaptativo con el número de operaciones molestas para crear nodos de valor de la misma estructura en varios controladores desconectados.
3. ¿Estás utilizando atributos calculados? ¿Alguna vez has sentido que a partir del tercer o cuarto atributo calculado estás rompiendo los principios de OO y el código del controlador se está volviendo abultado?
4. ¿Cuántas veces intentas hacer un mapeo de contexto extraordinario entre nodos de valor? ¿Y sientes que estás tratando de encajar en las restricciones de mapeo de contexto en lugar de implementar la funcionalidad principal?
5. ¿Alguna vez has tenido dificultades para expresar restricciones de validación complejas? ¿Incluso tan obvias (suspiro) como la coincidencia de expresiones regulares? ¿O realmente complejas como la verificación de ISBN?
6. ¿Alguna vez has encontrado que las APIs de WebDynpro relacionadas con el contexto son bastante limitadas? Sin soporte para eventos de cambio de atributo, reglas de invalidación arcanas y poco convenientes, etc.

Si has respondido al menos algunas de las preguntas con "Sí, me sucede", entonces esta publicación es definitivamente para ti. Si no: Quién sabe, probablemente "volverás" más tarde. De todos modos, te desaconsejo enérgicamente que apliques las técnicas mencionadas a continuación si no existen tales problemas en tu desarrollo actual. No introduzcas complejidad solo porque crees que alguna técnica es genial. Pero "si": entonces:, bueno, a toda velocidad 😉

Descargo de responsabilidad / Garantía / Notas importantes

Primero, algunas de las técnicas mencionadas (validación / restricciones de propiedad) dependen de cierto comportamiento de WebDynpro. Realmente no tengo idea de si es estándar o no. Probablemente, los moderadores serán bastante pacíficos y no eliminarán la publicación justo después de leer esta línea o me culparán por soluciones no estándar. Supongo que la funcionalidad existente hasta el momento es muy importante, y si surgen problemas de compatibilidad, es posible discutirlos en los comentarios.

Segundo, he desarrollado mi código utilizando NW04s o Paris (sí, soy definitivamente un afortunado ;). He hecho todo lo posible para no romper la compatibilidad con versiones anteriores. Pero si tienes algún problema al retroceder a SP11+ podemos discutir los problemas también en los comentarios.

Tercero ("por último"), no intentaré describir cómo programar JavaBeans; el sitio relacionado Java tiene suficiente información, al igual que JavaDocs incluidos con NetWeaver.

Caso de uso

Imagina que tenemos que desarrollar un componente para editar un equipo de empleados. Digamos que necesitamos crear un editor para el personal de un proyecto. Inicialmente, el editor está preinicializado por cierto equipo de usuarios de una parte externa como un motor sofisticado de asignación de personal (simplemente lo emulamos). El usuario puede agregar / eliminar empleados del equipo, así como editar propiedades de los existentes (dejamos la magia de UME fuera de este ejemplo). Mientras el editor proporciona una gran flexibilidad al usuario final, impone una restricción importante: la variación del salario total del equipo no debe exceder cierto porcentaje del salario inicial del equipo. El usuario debe ver una retroalimentación inmediata sobre esta violación de la restricción. Además, al salir del editor necesitamos informar al componente externo sobre los cambios delta en el equipo: el editor debe proporcionar información exacta sobre:

1. empleados actualizados de la lista original
2. empleados eliminados de la lista original
3. empleados recién agregados

Sin más demora, comencemos con la implementación.

Modelado de JavaBeans

Primero, crearemos (casi) JavaBeans regulares para nuestro caso de uso. Aquí discutiré el resultado final, sin embargo, en realidad es el resultado de varios ensayos y refactorizaciones.

Bien, tenemos que definir nuestro Employee JavaBean. Es solo una clase Java regular con métodos de acceso/mutador de propiedades correspondientes. Por cierto, si estás desarrollando tus JavaBeans desde cero, te recomiendo el siguiente camino:

1. Crear clase con campos privados para propiedades.
2. Utilizar la opción Generar Getter / Setter de Source / Eclipse para generar métodos de acceso / mutador.
3. Ajustar los tipos de retorno de los métodos si difieren del tipo de campo. En nuestro caso, la propiedad birthDate
   SAP ABAP

   

   Pedro Pascal

   Se unió el 07/03/2018
   Responder