El mal olor de las transacciones.

En mi post GeneXus TILO: Que características me gustaría que tuviera, sugería que los objetos Transacción deberían dividirse en varios objetos.

Hay varios motivos para sugerir esta división, pero el principal es que el código que hay que escribir o especificar en las transacciones empieza a tener "mal olor".

Pongo algunos ejemplos para que quede mas claro:

WIN y WEB
Cuando se tienen generador WEB y WIN en la misma KB, si una transacción es compartida en los dos generadores, es muy probable que se termine con código en los eventos y reglas de la forma:

[WEB]{
//Codigo para WEB
}
[WIN] {
//Codigo para WIN
}

Esto dificulta la  comprensión de lo que hace cada objeto y ensucia mucho el árbol de llamadas entre objetos, pues es difícil saber que objeto llama a otro en cada ambiente.

Transacciones con BLOB.
Otro ejemplo, si la transacción que es usada en WIN y WEB, tiene un campo BLOB, en WEB se genera automáticamente la selección de archivo y el subido a la base de datos y la asignación de los atributos de nombre y extensión, pero en WIN hay que incluir código para realizar esto.

BusinessComponent como web service.
Las transacciones pueden usarse como BC y estos se pueden exponer como web services, pero únicamente se soporta un protocolo.  Que pasa si queremos tener el mismo BC con protocolo SOAP y REST?  Hay que duplicar la transacción para poder soportarlo, con el consiguiente problema en el mantenimiento de estructuras y reglas.

Transacciones de varios niveles en generador SmartDevices. 
Hoy no se soportan transacciones de varios niveles en los generadores de  dispositivos móviles  Si tengo una transacción que uso en otro generador y pretendo usarla en una aplicación para dispositivo móvil  debería salvarla como otros dos objetos, cada uno con un nivel.

Forms para diferentes plataformas. 
Hoy las transacciones tienen WIN form y WEB form. A pesar que mi KB tenga únicamente un generador WEB, igual se salva, valida y demás el WIN form. Muchas veces, estoy trabajando en una KB migrada de win a web, y hoy es totalmente WEB, pero no me lo deja salvar, porque falta determinado atributo en el formulario win.

Analizando todos estos "problemas" planteados, vemos que se pierde la ortogonalidad pues los cambios hay que realizarlos en varios lados.

Creo que una forma de resolverlo seria dejar los Business Component con estructura + reglas de validación.
Las reglas pueden especificarse por niveles y los BC podrían generarse por niveles o todos los niveles del mismo.

En ellos es que se harían las definiciones de NULL, subtipos, integridad referencial, indices etc. Las reglas únicamente devuelven mensajes, y no se pueden llamar a objetos que tengan formularios (pantallas). Estas estructuras serian mantenidas por las personas que administran el modelo de datos y por tener una gran influencia en todo el modelo podrían tener controles de calidad y auditoria adicionales.

Se crean objetos propios para cada plataforma para el ingreso de datos, que se relacionan con dichos BC desde donde heredan la estructura y sus reglas.  Estos sustituirian a las WINForm y WEBForm actuales.
Siguiendo la tendencia actual, los mismos se generarían con editor estilo pattern. Para crear/cambiar estos objetos no se necesitaría ser un programador de gran experiencia y pues no podria modificar la estructura de los datos, ni influir en otros programas mas que los llamados o los que lo llaman.

Con las transacciones actuales, un programador puede borrar un atributo de la estructura, porque en su programa de ingreso de datos no lo necesita mas, y pueden dejar de funcionar otros programas que nada tienen que ver con lo que el esta haciendo.

Realizar este cambio es mucho mas fácil decirlo que hacerlo, pero si pudiera hacerse creo que quedaría todo con un olor mucho mas agradable.

Las transacciones son por lejos, los objetos mas poderosos de GeneXus, siendo un modelo muy útil de una parte de la realidad. Creo que cambiándolo un poco, podría adaptarse mejor a la realidad actual y mas importante aun a los cambios que vengan en el futuro.