¿Cuáles son las ventajas y desventajas de la Sesión de la Fachada Core J2EE Patrón?

Question

¿Cuáles son las ventajas y desventajas de la Sesión de la Fachada Core J2EE Patrón?

¿Cuáles son los supuestos que hay detrás de ella?

Son estos supuestos válidos en un determinado medio ambiente?

Answer 1

Fachada de sesión es un fantástico patrón - es realmente una versión específica de la Empresa Fachada patrón.La idea es atar la funcionalidad empresarial en paquetes discretos - como TransferMoney(), Retirar(), Depósito()...De modo que su interfaz de usuario código de acceso a las cosas en términos de las operaciones de negocio en lugar de bajo nivel de acceso a datos o de otros detalles que no debería estar preocupado.

Específicamente con la Fachada de Sesión - utilizar una Sesión de EJB para actuar como el negocio de la fachada - lo cual es bueno porque entonces usted puede tomar ventaja de todos los J2EE servicios (autenticación/autorización, transacciones, etc)...

Espero que esto te ayuda...

Answer 2

La principal ventaja de la Fachada de Sesión patrón es que se puede dividir una aplicación J2EE en grupos lógicos mediante la funcionalidad de negocios.Una Sesión de Fachada será llamado por un POJO de la interfaz de usuario (es decir,un Negocio Delegado), y tener referencias apropiadas a los Objetos de Acceso a Datos.E. g.un PersonSessionFacade sería llamado por el PersonBusinessDelegate y, a continuación, podría llamar a la Ctx.Los métodos de la PersonSessionFacade será, al menos, siga el patrón CRUD (Create, Retrieve, Update y Delete).

Normalmente, la mayoría de Sesión de Fachadas se implementan como apátridas de sesión de Ejb.O si estás en la Primavera de la tierra el uso de AOP para las transacciones, se puede crear un servicio de POJO que puede ser todos los puntos de unión de su administrador de transacciones.

Otra de las ventajas de la SessionFacade patrón es que cualquier desarrollador J2EE con un mínimo de experiencia va a entender de inmediato que.

Desventajas de la SessionFacade patrón:supone una forma específica de la arquitectura de la empresa que está limitada por los límites de la J2EE 1.4 especificación (ver Rod Johnson libros para estas críticas).La mayoría de dañar la desventaja es que es más complicado de lo necesario.En la mayoría de las empresa web aplicaciones, necesitará un contenedor de servlets, y la mayoría de la tensión en una aplicación web será en el nivel que se encarga de HttpRequests o acceso a bases de datos.En consecuencia, no parece que vale la pena implementar el contenedor de servlets en un proceso independiente del espacio desde el contenedor de EJB.I. e.las llamadas remotas a los Ejb crear más dolor que ganar.

Answer 3

Rod Johnson afirma que la principal razón por la que te gustaría usar una Fachada de Sesión es si estás haciendo las transacciones gestionadas por contenedor - que no son necesarias más modernos marcos (como la Primavera).

Él dice que si usted tiene la lógica de negocio - poner en el POJO.(Que estoy de acuerdo con - creo que es un mayor enfoque orientado a objetos - en lugar de implementar una sesión de EJB.) http://forum.springframework.org/showthread.php?t=18155

Feliz de escuchar contraste de argumentos.

Answer 4

Parece que siempre que se hable acerca de cualquier cosa J2EE relacionados -, siempre hay un montón de supuestos detrás de las escenas - que la gente asume de una manera o de la otra - lo que lleva a la confusión.(Yo probablemente podría haber hecho la pregunta más clara también.)

Suponiendo que (a) queremos utilizar las transacciones gestionadas por contenedor en un sentido estricto, a través de la especificación de EJB, a continuación,

Sesión de fachadas son una buena idea - porque abstraen el bajo nivel de transacciones de base de datos para ser capaz de proporcionar el más alto nivel de la aplicación de gestión de transacciones.

Suponiendo (b) que significa el general concepto arquitectónico de la sesión de la fachada - entonces

La disociación de los servicios y de los consumidores y proporcionar una interfaz amigable en la parte superior de esto es una buena idea.La informática se ha solucionado un montón de problemas 'agregar una capa adicional de indirección'.

Rod Johnson escribe "SLSBs con interfaces remotas proporcionan una muy buena solución para aplicaciones distribuidas construido sobre RMI.Sin embargo, esto es una minoría requisito.La experiencia ha demostrado que no queremos utilizar la arquitectura distribuida, a menos que obligado por los requisitos.Todavía podemos remoto del servicio de los clientes si es necesario mediante la implementación de una comunicación remota de la fachada en la parte superior de una buena co-ubicado modelo de objetos." (Johnson, R "J2EE Desarrollo sin EJB" p119.)

Suponiendo (c) las que consideran que la especificación de EJB (y, en particular, la sesión de fachada de componentes) a ser una mancha en el paisaje de un buen diseño a continuación:

Rod Johnson escribe "En general, no hay muchas razones por las que usted podría utilizar un local SLSB a todos en un Muelle de la aplicación, como la Primavera proporciona más capacidad declarativa de gestión de transacciones de EJB, y la CMT es normalmente la principal motivación para el uso de locales SLSBs.Así que puede que no necesite th EJB capa en todo." http://forum.springframework.org/showthread.php?t=18155

En un entorno donde el rendimiento y la escalabilidad del servidor web son las principales preocupaciones - y el costo es un problema, y luego la sesión de la fachada de la arquitectura se ve menos atractiva - puede ser más simple para hablar directamente a la base de datos (aunque esto es más acerca de la jerarquización.)