JSF2 - respaldado por EJB o ManagedBean?

Question

Como estoy aprendiendo JSF2, me di cuenta de que no estoy seguro de lo que deberían ser los componentes de respaldo. Desde el punto de vista del diseño, ¿cuál es la diferencia entre EJB y @ManagedBeans?

Al final voy a usar JPA, por lo EJB es una elección natural para capa de negocio. ¿Es una buena práctica utilizar EJB directamente de JSF (como se explica href="http://www.adam-bien.com/roller/abien/entry/ejb_3_1_killed_the" aquí )?

En el momento me estoy inclinando hacia el uso de @ManagedBeans para los componentes que no necesitan acceso a la capa de negocio (por ejemplo, ayudantes de vista) o se ocupan de los datos de petición / sesión. Para otros fines, por ejemplo, listado de algo en una cuadrícula, me gustaría acceder directamente EJB.

¿Es este un buen diseño? ¿Debo usar @ManagedBeans para todos los beans de respaldo para el bien de la separación de la capa limpia, aunque en algunos casos sólo se delegan en EJB?

Answer 1

Una pregunta muy válida, pero supongo que la respuesta depende de la "rigurosidad" de la aproximación para su proyecto. En efecto, existe un poco de redundancia entre bean de respaldo JSF y EJB tanto como poner en práctica algunas de lógica de negocios.

En un ideales el uso de características de JSF con converters, rendered, validator, etc. el bean de respaldo podría de hecho ser código de lógica de negocio limpio. Pero en la práctica algo de lógica relacionados presentación con frecuencia se escapa en ella.

Esta lógica relacionada presentación, lo ideal sería que no sea en un EJB. Esta lógica relacionada presentación puede depender del paquete de caras, pero no es necesario. Es lo que hace que hacen que sea relacionado con la presentación o no.

Un modelo de componente unificado tiene algunas ventajas sin embargo. Y es el enfoque adoptado por costura y primavera . En ambos casos, el componente de negocios con la transacción declarativa, etc. puede ser utilizado directamente en JSF (primavera no utiliza EJB pero proporcionan un modelo similar). Sin embargo purista EJB diría que se debe disociar los dos.

Así que para mí es en última instancia una cuestión de gusto y el tamaño del proyecto. Me puedo imaginar que para un proyecto pequeño / medio utilizando EJB en JSF funciona bien. Para el proyecto más grande donde este rigor es fundamental, asegúrese de que no atornillar las capas.

Answer 2

En Java EE 6 existe un cierto solapamiento entre los distintos granos gestionados:. Habas JSF administrados (@ManagedBean), frijoles (CDI) y @Named beans EJB (@Stateless, @Statefull, @Singleton) logró

En la capa de vista no veo ninguna ventaja particular para pegarse con @ManagedBean. La variante CDI @Named parece ser capaz de hacer lo mismo y más, por ejemplo proporcionarle acceso a la alcance de la conversión.

El pensamiento actual parece ser que con el tiempo el modelo de componentes EJB también ser adaptado como un conjunto de anotaciones CDI. Sobre todo miembro de un grupo de expertos Reza Rahman frecuencia alude a esto. Véase, por ejemplo inyección de dependencias en Java EE 6 - Parte 1

Por el momento esto no ha sucedido, por lo que los granos de EJB siguen siendo el lugar más fácil de poner la lógica de negocio, especialmente cuando se utiliza JPA para la persistencia.

Sin embargo, si o no CDI obtendrán las capacidades de EJB, en mi humilde opinión, sigue siendo un mejor práctica utilizar un grano separado para el concepto de "Copia de frijol" y un grano separado para la "lógica de negocio".

El bean de respaldo puede ser muy delgado, apenas contiene algunas referencias para modelar objetos y servicios (EJBs). Métodos de acción de la bean de respaldo puede delegar casi directamente a los servicios, pero su valor añadido está en proporcionar al usuario información (añadiendo FacesMessages sobre el éxito o el fracaso) y hacer pequeñas modificaciones de interfaz de usuario (por ejemplo, el establecimiento de un valor booleano que falsa que muestra algunos de diálogo) .

Los Servicios (lógica de negocio) no deben saber nada acerca de cualquier presentación en particular. Deben ser igualmente bien utilizable a partir de beans de respaldo JSF, JAX-RS, servlets, los clientes remotos independientes Java SE o lo que sea.

Incluso si todos los granos se convertirían en los granos de CDI, a continuación, esto no cambia esta división básica de la responsabilidad.

Answer 3

Interesante artículo, no sabía de eso. Sin embargo, para mí este artículo huele más a una diatriba hacia beans JSF administrados. También apretados-parejas EJB con JSF. Es quizá interesante en aplicaciones pequeñas (personales), pero probablemente no en aplicaciones SOA mundo real en el que le gustaría tener un control total sobre el EJB ha sido atendida.

En cuanto a cuál usar para lo que, sólo se pegaba a @ManagedBean para denotar un modelo JSF -que está ligado a uno o más puntos de vista específicos JSF. Se puede utilizar perfectamente para @EJBs lógica no JSF específicos de negocios y / o datamodels. Puede inyectarse @EJBs en un modelo de JSF y delegar en los métodos de acción y tal vez también getters / setters, pero no se debe hacer a la inversa, es decir, no definen el modelo JSF en una @EJB, esto conduce a un acoplamiento apretado y haría @EJBs inutilizable fuera del contexto JSF. En lo que respecta, su diseño suena bien, siempre y cuando usted mira a no importar nada de paquete javax.faces en la clase @EJB.

Answer 4

Al llamar EJB desde el XHTML, se está introduciendo acoplamiento ajustado entre la elección de la aplicación de la vista y de negocios de nivel.

Si utiliza un bean gestionado llamar un EJB, [o incluso, poner en un delegado de negocio], usted será capaz de cambiar a cabo su capa de negocio por completo a la primavera sin afectar a la capa de vista (XHTML).

¿Es técnicamente posible, y muy fácil para que usted (JSR 299) sea capaz de utilizar EJB como su bean gestionado, y eso es probablemente lo que estos vendedores quieren que hagas - Obtener pegado a lo específico. Pero si eso es una cosa correcta de hacer? -. No