Separar entidades de la capa de presentación

Ayuda
Sergio
2013-05-06
2013-05-09
  • Sergio
    Sergio
    2013-05-06

    Hola Javier, en primer lugar quiero felicitarte por tu iniciativa, tu trabajo y dedicación!

    Estamos usando openxava hace unos meses y queremos organizar nuestro código fuente separándolo en capas (o niveles) de presentación y negocio. Para eso estamos pensando en tener un jar específico para todo lo que es presentación, que está prácticamente hecho en openxava, y tener un jar separado para las reglas de negocio que incluye el modelo de entidades y todo lo que es acceso a base de datos. Esto es un problema porque las annotations de openxava tienen que estar junto con las entidades, entonces surgió la idea de usar apenas annotations de JPA en las entidades y substituir las annotations de openxava por configuraciones en archivos XML. Estos archivos de configuración podrían ser colocados en la capa de presentación cumpliendo así nuestro objetivo.

    Me gustaría saber tu opinión sobre el tema, si es posible hacerlo de esa forma o si hay alguna alternativa.

    Muchas gracias,
    Sergio.

     
  • Javier Paniza
    Javier Paniza
    2013-05-08

    Hola Sergio,

    desde el punto de vista técnico se podría adaptar OpenXava para declarar las vistas fuera de la entidades. De hecho ya tenemos una especificación XML para definir las vistas. Actualmente OpenXava lee o bien el componente XML o bien la entidad JPA, pero no ambos, se trataría de cambiar el código para leer ambas especificaciones y sumarlas. No es mucho trabajo, porque lo dificil ya está hecho.

    Desde el punto de vista espiritual es un atentando contras los principios básicos de OpenXava. La razón es que OpenXava nació como una reacción aversa a los sistemas estructurados en capas tecnológicas. Los que hicimos OpenXava trabajabamos con sistemas basados en capas tecnológicas y al final nunca haciamos cambios aislados en una sola capa y sin embargo estabamos haciendo constantementes cambios en la estructura de los datos y la lógica que se esparcían por multitud de fichero. Se trata de que si quieres añadir una propiedad no tengas que tocar en 10 archivos diferentes.

    Yo no digo que separar la lógica de negocio, del acceso a la base de datos y de la presentación sea malo por sí mismo, pero no es práctico para aplicaciones de gestión. A la hora de organizar el código no debemos seguir principios espirituales sino definir una estructura que se adapteal uso que vamos a hacer del código y para una aplicación de gestión es mejor un enfoque basado en componentes de negocio (agrupar todo lo referente a un concepto de negocio en un mismo lugar) que en capas tecnológicas.

    Si para una concepto de negocio, digamos Factura por ejemplo, tienes tres archivos uno de Java, uno con la UI y otro con el mapeo. Realmente tienes la misma estructura repetida 3 veces, lo cual no es DRY; y has de estar toda tu vida sincronizando los 3 archivos.

    Obviamente esto es sólo un punto de vista, pero es el punto de vista en el que está basado OpenXava.


    Ayuda a otros en este foro como yo te ayudo a ti.
    ¿Necesitas más ayuda? Usa el soporte profesional de OpenXava

     
  • Sergio
    Sergio
    2013-05-08

    Ok Javier, entiendo tu postura e creo que está correcta, pero dejame explicarte porque tenemos esta necesidad. El sistema que estamos desarrollando es un sistema transaccional de alto rendimiento, que no depende de una interfaz gráfica para funcionar, escrito en C/C++ (para el core) y JAVA (para las reglas de negocio). Todo el acesso a la base de datos está escrito en JAVA usando JPA. El sistema está compuesto por vários módulos, cada uno con una función específica (tenemos un módulo que encapsula el modelo de datos en forma de entidades de JPA, tenemos otros módulos que encapsulan reglas de negocio, etc).
    Hace unos meses empezamos a usar openxava para ser la interfaz gráfica y nos gustó mucho! es una herramienta fantástica que nos ahorró mucho tiempo, pero como consecuencia nuestras entidades, que antes tenían solamente annotations de JPA, pasaron a tener también annotations de openxava y esto no es lo ideal por dos motivos: el primero es que como las entidades tienen annotations de openxava, nos vemos obligados a incluir el openxava en nuestros módulos de procesamiento de transacciones que no usan interfaz gráfica, pero que acceden a la base de datos; y el segundo es que para alterar alguna parte visual (de presentación) probablemente sería necesario alterar los mismos códigos fuente de las entidades (del módulo que encapsula el modelo de datos).
    Bien, quería colocarte en el contexto para que entiendas que no es un capricho sino que realmente existe la necesidad. Aunque estoy consciente de que es un caso muy específico y que probablemente casi nadie tenga este tipo de problema.

    Como comentás en tu respuesta, habría que alterar el openxava para poder interpretar al mismo tiempo annotations de JPA y archivos xml de configuración de view. No sé si tienen interés en hacer este tipo de alteración ya que me imagino que tendrán una lista de funcionalidades mas importantes que necesitan ser implementadas.

    En mi caso lo que puedo hacer es agregar un paso mas en el script de compilación. Sería un pré-procesador de archivos fuentes de entidades que generaría entidades sin las annotations de openxava (apenas con annotations de JPA). Estas entidades generadas por el pré-procesador serían usadas por los módulos de negocio de procesamiento de transacciones. Mientras que las entidades originales (con annotations de JPA e openxava) serían usadas por los módulos de la interfaz gráfica. No es lo ideal pero resuelve el problema mas crítico.

    Te agradezco nuevamente!

    Sergio.

     
  • Javier Paniza
    Javier Paniza
    2013-05-09

    Hola Sergio,

    al mismo tiempo annotations de JPA y archivos xml de configuración de view.
    No sé si tienen interés en hacer este tipo de alteración ya que me imagino
    que tendrán una lista de funcionalidades mas importantes que necesitan ser
    implementadas.

    Tenemos más de 100 funcionalidades pendientes apuntadas en el gestor de incidencias. Pero el código abierto es una meritocracia, por eso te propongo lo siguiente: hazlo tú y yo lo añadiré a OpenXava. No es muy complicado y me puedes preguntar todo lo que necesites. ¿Qué te parece?


    Ayuda a otros en este foro como yo te ayudo a ti.
    ¿Necesitas más ayuda? Usa el soporte profesional de OpenXava

     
  • Sergio
    Sergio
    2013-05-09

    Ok Javier, voy a analizar la mejor forma de hacerlo.