ALGUNOS PATRONES J2EE
Sun Java Center - J2EE Patterns
A continuación pongo pequeños comentarios, basándome en los patrones clásicos de GoF, de los patrones J2EE más conocidos. Doy por hecho que primero os habréis leído la definición de cada patrón.
* Front Controller: ya conocido, es un MVC donde el controller utilizar una serie de dispatchers.
* Composite View Pattern: las JSP están constituidas por conjuntos de JSPs, a través de "includes".
* Session Facade: al igual que el patrón clásico Facade, en este caso es un Session Bean el que ejerce como tal.
* Service Locator: utilización de un singleton que permite encontrar el resto de EJBs. Esto permite no tener que utilizar JNDI constantemente desde el servidor.
* Value Object: en la comunicación c/s, cuando un EJB tiene multitud de propiedades, el acceso constante degrada las prestaciones. Para ello, un EJB devuelve un objeto ValueObject con todas sus propiedades, de manera que el cliente puede procesarlas localmente.
* Business Delegate: llega más allá del SessionFacade, encapsulando todo el tratamiento con los objetos de negocio (es quien interactúa con el cliente y con el service locator, por ejemplo). Se puede aprovechar como proxy para temas de caché, reintentos, etc.
* Data Access: las tareas sobre los datos suelen ser independientes del formato de esos datos. Es básicamente un Adapter.
* View Helper: encapsulamiento de la interacción de la lógica de negocio con la JSP mediante helpers (JavaBeans, por ejemplo), con métodos getters y setters si es posible.
* Dispatcher View: interactúa con el Front Controller para controlar el acceso a la vista JSP. También funciona de manera que la JSP tenga un View Helper. De esa manera se soluciona completamente el problema de acoplamiento entre las dos capas.
* Service To Worker: parecido al Dispatcher View, sólo que mientras que el Dispatcher View no instancia View Helpers, por lo que se entiende que el acceso a los datos externos sólo ocurre cuando ya se ha accedido a la vista, en el caso del Service To Worker el FrontController sí accede a diferentes View Helpers, de manera que el Dispatcher, cuando selecciona la vista, también interactúa con estos ViewHelpers. Básicamente, la diferencia fundamental es que el Dispatcher se preocupa de la elección del conteindo del modelo cuando se crea la vista, mientras que el ServiceToWorker ya crea un modelo intermedio antes.
* Value List Handler: También llamado Page-by-page Iterator. Stateful session bean que accede al DAO para que el cliente no tenga que realizar múltiples peticiones a través de la red. También ejerce de fachada.
* Fast Lane Reader: cuando los datos no cambian mucho y son de sólo lectura, la utilización de EJB Finders es tediosa y mala para las prestaciones del sistema. Este patrón accede directamente a la fuente de datos, e interactúa con el cliente, como si fuera un Entity Bean.
* Transfer Object: a mí me da la sensación de que es un Value Object con otro nombre, centrado en entities.
* Transfer Object Assembler: debido al problema de siempre con las comunicaciones, este patrón lo que hace es devolver al cliente un sólo objeto que sea "resumen" de diversos valores devueltos por session beans, entity beans, DAOs, etc.
* Composite Entity: igual que el Transfer Object, pero centrado en un Entity Bean particular.
En cuanto a la tesis, además de ver el resto de patrones J2EE para considerarlos en el diseño, estaría bien echar un vistazo al documento de diseño de VINI, donde parece que hay buenos diseños que estudiar. En principio yo tiraría por utilizar el patrón Data Access Object, tal y como recomienda J2EE y Fowler, pero habrá que ver.
* Composite Entity: un mapping directo entre el modelo relacional y el objetual (entity beans) no tiene en cuenta que los EBeans son mejores cuando la granularidad es gruesa. El Composite Entity modela un conjunto de objetos interrelacionados en lugar de representarlos independientemente. De esta manera sólo se tiene un Entity Bean, el que se comunica con este patrón, en lugar de considerar cada elemento compuesto como un entity bean.
Sun Java Center - J2EE Patterns
A continuación pongo pequeños comentarios, basándome en los patrones clásicos de GoF, de los patrones J2EE más conocidos. Doy por hecho que primero os habréis leído la definición de cada patrón.
* Front Controller: ya conocido, es un MVC donde el controller utilizar una serie de dispatchers.
* Composite View Pattern: las JSP están constituidas por conjuntos de JSPs, a través de "includes".
* Session Facade: al igual que el patrón clásico Facade, en este caso es un Session Bean el que ejerce como tal.
* Service Locator: utilización de un singleton que permite encontrar el resto de EJBs. Esto permite no tener que utilizar JNDI constantemente desde el servidor.
* Value Object: en la comunicación c/s, cuando un EJB tiene multitud de propiedades, el acceso constante degrada las prestaciones. Para ello, un EJB devuelve un objeto ValueObject con todas sus propiedades, de manera que el cliente puede procesarlas localmente.
* Business Delegate: llega más allá del SessionFacade, encapsulando todo el tratamiento con los objetos de negocio (es quien interactúa con el cliente y con el service locator, por ejemplo). Se puede aprovechar como proxy para temas de caché, reintentos, etc.
* Data Access: las tareas sobre los datos suelen ser independientes del formato de esos datos. Es básicamente un Adapter.
* View Helper: encapsulamiento de la interacción de la lógica de negocio con la JSP mediante helpers (JavaBeans, por ejemplo), con métodos getters y setters si es posible.
* Dispatcher View: interactúa con el Front Controller para controlar el acceso a la vista JSP. También funciona de manera que la JSP tenga un View Helper. De esa manera se soluciona completamente el problema de acoplamiento entre las dos capas.
* Service To Worker: parecido al Dispatcher View, sólo que mientras que el Dispatcher View no instancia View Helpers, por lo que se entiende que el acceso a los datos externos sólo ocurre cuando ya se ha accedido a la vista, en el caso del Service To Worker el FrontController sí accede a diferentes View Helpers, de manera que el Dispatcher, cuando selecciona la vista, también interactúa con estos ViewHelpers. Básicamente, la diferencia fundamental es que el Dispatcher se preocupa de la elección del conteindo del modelo cuando se crea la vista, mientras que el ServiceToWorker ya crea un modelo intermedio antes.
* Value List Handler: También llamado Page-by-page Iterator. Stateful session bean que accede al DAO para que el cliente no tenga que realizar múltiples peticiones a través de la red. También ejerce de fachada.
* Fast Lane Reader: cuando los datos no cambian mucho y son de sólo lectura, la utilización de EJB Finders es tediosa y mala para las prestaciones del sistema. Este patrón accede directamente a la fuente de datos, e interactúa con el cliente, como si fuera un Entity Bean.
* Transfer Object: a mí me da la sensación de que es un Value Object con otro nombre, centrado en entities.
* Transfer Object Assembler: debido al problema de siempre con las comunicaciones, este patrón lo que hace es devolver al cliente un sólo objeto que sea "resumen" de diversos valores devueltos por session beans, entity beans, DAOs, etc.
* Composite Entity: igual que el Transfer Object, pero centrado en un Entity Bean particular.
En cuanto a la tesis, además de ver el resto de patrones J2EE para considerarlos en el diseño, estaría bien echar un vistazo al documento de diseño de VINI, donde parece que hay buenos diseños que estudiar. En principio yo tiraría por utilizar el patrón Data Access Object, tal y como recomienda J2EE y Fowler, pero habrá que ver.
* Composite Entity: un mapping directo entre el modelo relacional y el objetual (entity beans) no tiene en cuenta que los EBeans son mejores cuando la granularidad es gruesa. El Composite Entity modela un conjunto de objetos interrelacionados en lugar de representarlos independientemente. De esta manera sólo se tiene un Entity Bean, el que se comunica con este patrón, en lugar de considerar cada elemento compuesto como un entity bean.
Comments