Qué hacer y qué no hacer: Contexto Webdynpro.

Me parece que estas reglas están dirigidas a mejorar el rendimiento.

Tengo algunas observaciones sobre un par de estas reglas:

• Sin ningún requisito (uso en Varios Controladores) no cree Contexto en el nivel de controlador de componentes, Si es necesario, cree contextos locales, por ejemplo, en vistas

El controlador de componentes es el concentrador central para su contexto. Si en algún momento tiene un nodo de contexto que se comparte en varias vistas, debe crear el nodo en el controlador de componentes y asignarlo a otras vistas.

Los nodos específicos de una determinada vista se pueden crear directamente en el contexto de la vista, pero por legibilidad y uniformidad, a menudo elijo centralizar todos mis nodos de contexto y métodos de suministro en el controlador de componentes.

• Utilice nodos singleton si se necesitan anidamientos (detalles maestros)

Los nodos singleton son buenos para el rendimiento, porque solo mantiene una instancia de su nodo en memoria, en lugar de tener varias instancias para cada objeto padre (inactivo). Sin embargo, es mejor que sepa lo que está haciendo porque si se encuentra en una situación en la que necesita varios elementos primarios activos (repetidor de filas, tablas anidadas, árboles, tablas de selección múltiple…) el nodo singleton volcará su aplicación.

Si no conoce bien el principio de los nodos singleton, o cuando el rendimiento no es un problema, no utilice nodos singleton.

• No utilice atributos dinámicos (IF_WD_CONTEXT_NODE_INFO – > ADD_ATTRIBUTE)

Si puede usar atributos de contexto definidos estáticamente, utilice atributos estáticos. Sin embargo, habrá situaciones en las que tendrá que crear su contexto dinámicamente. En esos casos, no tiene otra opción que agregar atributos dinámicos. Sin embargo, estoy de acuerdo en que debe evitar la programación de contexto dinámico (y la programación de vista dinámica) tanto como sea posible.

• Usar datos con estructura de contexto para BIND_TABLE

No es un requisito difícil, Internamente, las operaciones de enlace usan un movimiento correspondiente y mantienen la tabla original en una variable de sombra. Aunque el movimiento correspondiente es, según se informa, malo para el rendimiento. (Digo supuestamente, porque he hecho pruebas de mí mismo y no pude encontrar ninguna diferencia significativa)

• Actualizar el contexto solo si los datos realmente tienen que actualizarse

Depende de lo que quieres decir con actualizar?

• No cree largas cadenas de asignación de contexto.

?

• Utilice las funciones de Registro de cambios de contexto para detectar la entrada del usuario. Esto tiene beneficios de rendimiento particulares, mientras que un usuario de la aplicación modifica solo una pequeña cantidad de datos en una vista y muestra una gran cantidad de datos mixtos.

Verdadero. El registro de cambios de contexto puede ser muy poderoso cuando se usa de manera dinámica.

Pero también es muy avanzado. Tengo un fragmento para revisar todos los cambios en un contexto, asignar los datos a la variable apropiada en la clase de asistencia (campo en estructura o campo en una fila en una tabla interna) y llamar dinámicamente a un método de controlador (si existe). Compartí este fragmento con muchos desarrolladores altamente calificados. Hasta la fecha, solo 2 entendían realmente lo que hacía y eran capaces de aplicarlo en sus propios componentes.

Las reglas que mencionas son lo suficientemente interesantes, pero como Steve mencionó, es posible que quieras elaborar el propósito y la idea subyacente.

¡Salud!