java - outputtext - JSF2: ¿está respaldado por EJB o ManagedBean?
<h:outputtext (4)
Al llamar a EJB desde su XHTML, está introduciendo un fuerte acoplamiento entre la elección de implementación en la vista y el nivel de negocios.
Si usa un bean administrado para llamar a un EJB, [o incluso, póngalo en un delegado comercial], podrá cambiar su nivel de negocio completamente a Spring sin afectar la capa de vista (XHTML).
Es técnicamente posible, y es muy fácil para usted (JSR 299) poder utilizar EJB como su bean administrado, y eso es probablemente lo que estos proveedores quieren que haga: pegarse a detalles específicos. Pero si eso es algo correcto que hacer? - No.
Cuando estoy aprendiendo JSF2, me di cuenta de que no estoy seguro de cuáles deberían ser los componentes de respaldo. Desde el punto de vista del diseño, ¿cuál es la diferencia entre los EJB y @ManagedBeans ?
Al final, voy a utilizar JPA, por lo que EJB es una opción natural para la capa empresarial. ¿Es una buena práctica usar EJB directamente desde JSF (como se explica here )?
En este momento me estoy inclinando hacia el uso de @ManagedBeans para componentes que no necesitan acceso a la capa de negocios (por ejemplo, ver ayudantes) o lidiar con los datos de solicitud / sesión. Para otros fines, por ejemplo, listar algo en una cuadrícula, accedería directamente a EJB.
¿Es este un buen diseño? ¿Debo usar @ManagedBeans para todos los beans de respaldo en aras de una separación de capa limpia, incluso si en algunos casos solo delegan en EJB?
Artículo interesante, no sabía sobre eso. Sin embargo, para mí este artículo huele más como una perorata hacia los beans administrados por JSF. También se ajusta a parejas EJB con JSF. Tal vez sea interesante en aplicaciones pequeñas (personales), pero probablemente no en aplicaciones de SOA del mundo real en las que le gustaría tener un control total sobre los EJB que se han revisado.
En cuanto a cuál usar para qué, me @ManagedBean a usar @ManagedBean para denotar un modelo JSF, que está vinculado a una o más vistas JSF específicas. Puede utilizar perfectamente @EJB s para lógica de negocios y / o modelos de datos no específicos de JSF. Puede inyectar @EJB s en un modelo JSF y delegarlo en métodos de acción y tal vez también en captadores / configuradores, pero no debe hacerlo al revés, es decir, no defina el modelo JSF en un @EJB , esto conduce a un acoplamiento estrecho y haría que @EJB inutilizable fuera del contexto JSF. Hasta el momento, su diseño suena bien, siempre y cuando no mire nada del paquete javax.faces en la clase @EJB .
En Java EE 6 hay cierta superposición entre los diferentes beans gestionados: JSF beans gestionados (@ManagedBean), CDI beans gestionados (@Named) y EJB beans (@Stateless, @Statefull, @Singleton).
En la capa de vista no veo ninguna ventaja en particular para seguir con @ManagedBean. La variante de CDI @Named parece ser capaz de hacer lo mismo y más, por ejemplo, proporcionarle acceso al alcance de conversión.
El pensamiento actual parece ser que, finalmente, el modelo de componente EJB también se actualizará como un conjunto de anotaciones de CDI. Especialmente el miembro experto del grupo Reza Rahman a menudo alude a esto. Ver, por ejemplo, inyección de dependencia en Java EE 6 - Parte 1
Por el momento, esto no ha sucedido, por lo que los beans EJB siguen siendo el lugar más fácil para poner la lógica empresarial, especialmente cuando se usa JPA para la persistencia.
Sin embargo, ya sea que CDI obtenga o no las capacidades de EJB, IMHO, sigue siendo una buena práctica usar un bean separado para el concepto de "bean de respaldo" y un bean separado para la "lógica de negocios".
El bean de respaldo puede ser realmente delgado, simplemente contiene algunas referencias a objetos y servicios de modelo (EJB). Los métodos de acción del bean de respaldo pueden delegar casi directamente a los servicios, pero su valor agregado es proporcionar comentarios al usuario (agregar FacesMessages en caso de éxito o fracaso) y realizar pequeñas modificaciones en la interfaz de usuario (por ejemplo, establecer un valor booleano en falso que muestra algún cuadro de diálogo) .
Los Servicios (lógica de negocios) no deben saber nada sobre ninguna presentación en particular. Deben ser igualmente utilizables desde los beans de respaldo JSF, JAX-RS, Servlets, clientes remotos independientes de Java SE o lo que sea.
Incluso si todos los beans se convertirían en beans CDI, esto no cambia esta división básica de responsabilidad.
Pregunta muy válida, pero supongo que la respuesta depende de la "rigurosidad" del enfoque para su proyecto. De hecho, existe un poco de redundancia entre el bean de respaldo JSF y EJB, ya que ambos implementan alguna lógica de negocios.
En un uso ideal de las funciones JSF con converters , rendered , validator , etc., el bean de respaldo podría ser un código lógico de negocio limpio. Pero en la práctica, algo de lógica relacionada con la presentación se filtra con frecuencia.
Esta lógica relacionada con la presentación idealmente no debería estar en un EJB. Esta lógica relacionada con la presentación puede depender del paquete de caras, pero no es necesaria. Es lo que hace que sea relacionado con la presentación o no.
Sin embargo, un modelo de componente unificado tiene algunas ventajas. Y es el enfoque adoptado por Seam y Spring . En ambos casos, el componente comercial con transacción declarativa, etc. se puede usar directamente en JSF (Spring no utiliza EJB, pero proporciona un modelo similar). Sin embargo, el purista de EJB diría que debes disociar los dos.
Así que para mí, en última instancia, es una cuestión de gusto y tamaño del proyecto. Puedo imaginar que para un proyecto pequeño / mediano usando EJB en JSF funciona bien. Para proyectos más grandes donde este rigor es crítico, asegúrese de no atornillar las capas.