Estructura de beans de respaldo JSF (mejores prácticas)

Question

Espero que en esta publicación, pueda obtener opiniones de las personas sobre las mejores prácticas para la interfaz entre las páginas JSF y los beans de respaldo.

Una cosa que nunca puedo resolver es la estructura de mis granos de respaldo. Además, nunca he encontrado un buen artículo sobre el tema.

¿Qué propiedades pertenecen a qué respaldo de frijoles? ¿Cuándo es apropiado agregar más propiedades a un bean dado en lugar de crear un nuevo bean y agregarle las propiedades? Para aplicaciones simples, ¿tiene sentido simplemente tener un solo bean de respaldo para toda la página, teniendo en cuenta la complejidad que implica inyectar un grano en otro? ¿Debería el bean de respaldo contener una lógica comercial real, o debería contener datos estrictamente?

No dude en responder estas preguntas y cualquier otra que pueda surgir.

---

En cuanto a la reducción de acoplamiento entre la página JSF y el bean de respaldo, nunca permita que la página JSF para acceder a las propiedades de cualquier propiedad bean de respaldo. Por ejemplo, nunca permito que algo como:

<h:outputText value="#{myBean.anObject.anObjectProperty}" /> 

que siempre requieren algo como:

<h:outputText value="#{myBean.theObjectProperty}" /> 

con un valor bean de respaldo de:

public String getTheObjectProperty() 
{ 
    return anObject.getAnObjectProperty(); 
} 

Cuando bucle sobre una colección , Utilizo una clase de contenedor para evitar profundizar en un objeto en una tabla de datos, por ejemplo.

En general, este enfoque se siente "correcto" para mí. Evita cualquier acoplamiento entre la vista y los datos. Por favor corrígeme si estoy equivocado.

Answer 1

Es posible que desee comprobar esto: making distinctions between different kinds of JSF managed beans.

Aquí es una descripción de los diferentes tipos de grano, como se define en el artículo anterior por Neil Griffin:

• Modelo Bean-Managed: Normalmente ámbito de sesión. Este tipo de frijol administrado participa en la preocupación "Modelo" del patrón de diseño MVC. Cuando vea la palabra "modelo", piense en DATA. Un modelo de bean JSF debe ser un POJO que siga el patrón de diseño de JavaBean con las propiedades de encapsulación getters/setters. El caso de uso más común para un bean modelo es ser una entidad de base de datos, o simplemente representar un conjunto de filas del conjunto de resultados de una consulta de base de datos.
• Backing Managed-Bean: Normalmente, solicite el alcance. Este tipo de beans gestionados participa en la preocupación de "Ver" del patrón de diseño de MVC. El propósito de un respaldo es apoyar la lógica de UI, y tiene una relación 1 :: 1 con una vista JSF, o un formulario JSF en una composición de Facelet. Aunque normalmente tiene propiedades de estilo JavaBean con getters/setters asociados, estas son propiedades de View, no del modelo subyacente de datos de la aplicación. Los beans de respaldo JSF también pueden tener métodos JSF actionListener y valueChangeListener.
• Controlador Manage-Bean: Normalmente, solicite el alcance. Este tipo de frijol administrado participa en la preocupación "Controlador" del patrón de diseño MVC. El propósito de un bean controlador es ejecutar algún tipo de lógica comercial y devolver un resultado de navegación al manejador de navegación JSF. Los beans controladores JSF generalmente tienen métodos de acción JSF (y no métodos actionListener).
• Soporte Managed-Bean: Normalmente, el alcance de la sesión o la aplicación. Este tipo de bean "admite" una o más vistas en la preocupación "Ver" del patrón de diseño de MVC. El caso de uso típico es el suministro de listas de ArrayList a JSF h: selectOneMenu que aparecen en más de una vista JSF. Si los datos en las listas desplegables son particulares para el usuario, entonces el bean se mantendrá en el alcance de la sesión. Sin embargo, si los datos se aplican a todos los usuarios (como una lista desplegable de provincias), el bean se mantendrá dentro del alcance de la aplicación, de modo que se pueda almacenar en caché para todos los usuarios.
• Utility Managed-Bean: Ámbito de aplicación normalmente. Este tipo de bean proporciona algún tipo de función de "utilidad" para una o más vistas JSF.Un buen ejemplo de esto podría ser un bean FileUpload que se puede reutilizar en múltiples aplicaciones web.

Answer 2

Es posible que no responda todas sus preguntas, ya que pocas parecen depender en cada caso.

• Esto está bien para tener una lógica de negocios en su bean de respaldo. Depende de dónde vienes. Si está practicando el diseño impulsado por el dominio, tendrá la tentación de incluir la lógica de negocios en el bean de respaldo o también puede ser lógica de persistencia. Ellos argumentan que por qué un objeto tan tonto. El objeto debe llevar no solo estado sino también comportamiento. Por otro lado, si considera la manera tradicional de hacer Java EE, puede tener la sensación de tener datos en su bean de respaldo, que también puede ser su bean de entidad, y otra lógica de negocios y persistencia en algún bean de sesión o algo así. Eso también está bien.

• Está perfectamente bien tener un único bean de respaldo para toda la página. No veo ningún problema con esto solo. Esto puede no parecer correcto, pero eso depende del caso.

• Su otra pregunta depende mucho más del caso que tenga entre manos. Preferiría dirigirme al dominio aquí, podría ser apropiado agregar propiedades al existente o crear un nuevo bean para eso. Lo que mejor se adapte. No creo que haya ninguna bala de plata para esto.

• Qué propiedades pertenecen a qué bean de respaldo. Bueno, ¿no depende del objeto de dominio? O puede ser que la pregunta no es tan clara.

Además, en su ejemplo de código dado, no veo ningún gran beneficio.

Answer 3

lo haría, no guarda necesaria sólo un bean de respaldo por página. Depende de la funcionalidad, pero la mayoría de las veces tengo un bean por página, ya que en su mayoría una página maneja una funcionalidad. Por ejemplo, en una página tengo un enlace de registro (voy a vincular con RegisterBean) y un enlace a la cesta de la compra (ShoopingBasketBean).

Uso este <: outputText value = "# {myBean.anObject.anObjectProperty}" /> como normalmente mantengo los beans como beans de acción que contienen objetos de datos. No quiero escribir un contenedor en mi bean de respaldo para acceder a las propiedades de mis objetos de datos.

Answer 4

Muy buena pregunta. Sufrí mucho con el mismo dilema cuando me mudé a JSF. Realmente depende de tu aplicación. Soy del mundo de Java EE, por lo que recomendaría tener la menor lógica de negocios posible en sus granos de respaldo. Si la lógica está puramente relacionada con la presentación de su página, entonces está bien tenerla en el bean de respaldo.

Creo que uno de los (muchos) puntos fuertes de JSF es en realidad el hecho de que puede exponer objetos de dominio directamente en los beans administrados. Por lo tanto, recomiendo encarecidamente el enfoque <:outputText value="#{myBean.anObject.anObjectProperty}" />, de lo contrario terminará haciendo demasiado trabajo para exponer manualmente cada propiedad. Además, sería un desastre al insertar o actualizar datos si encapsuló todas las propiedades. Hay situaciones en las que un solo objeto de dominio puede no ser suficiente. En esos casos, preparo un ValueObject antes de exponerlo en el bean.

EDITAR: en realidad, si va a encapsular cada propiedad de objeto que desea exponer, le recomiendo que en lugar de ello vincule componentes de UI al bean de respaldo y luego inyecte el contenido directamente en el valor del componente.

En términos de estructura de beans, el punto de inflexión para mí fue cuando ignoré por la fuerza todo lo que sabía sobre la creación de aplicaciones web y comencé a tratarlo como una aplicación GUI. JSF imita mucho a Swing y, por lo tanto, las mejores prácticas para desarrollar aplicaciones Swing también se aplicarían principalmente a la creación de aplicaciones JSF.

Answer 5

Creo que lo más importante con sus beans de respaldo es para separar sus lógicas. Si usted tiene una portada para un sistema CMS lo vería como una mala práctica de poner cada pieza de código en un grano porque:

1. El grano se volvería muy grande con el tiempo
2. Es más fácil para otras personas a encuentre lo que está buscando si están solucionando problemas en la página de inicio de sesión, si luego pueden simplemente buscar el archivo loginBean.java.
3. A veces hay pequeñas piezas de funcionalidad que se distinguen claramente del resto de su código, separando esta me imagino que haría más fácil para ti mismo, para obras/expandir este código en algo más grande, cuando ya se tiene un buen frijol con buena estructura.
4. Tener 1 big bean, para hacerlo todo, hará que sea más dependiente de la memoria si/cuando tienes que hacer declaraciones como esta MyBigBean bigBean = new MyBigBean(); en lugar de utilizar la funksjonality que realmente necesitas haciendo LoginBean loginBean = new LoginBean(); (Corrígeme si estoy mal aquí ???)
5. En mi opinión, la separación de los granos es como separar sus métodos. No desea 1 método grande que ejecute más de 100 líneas, sino más bien divídalo con nuevos métodos que manejen su tarea específica.
6. Recuerde, probablemente alguien que no sea usted también tendrá que trabajar en sus proyectos de JSF.

---

En cuanto al acoplamiento, yo no lo ve como una cuestión problemática para permitir que sus páginas JSF acceso también las propiedades de los objetos en su backingbean. Este es un soporte que está integrado en JSF, y realmente solo hace que sea más fácil de leer y construir imo. Ya estás separando estrictamente la lógica de MVC. Al hacerlo, ahorrará toneladas de líneas con getters y setters en su backingbean. Por ejemplo, los servicios web me dieron un objeto realmente grande, donde necesito usar algunas propiedades en mi presentación. Si tuviera que hacer un getter/setter para cada propiedad, mi bean se expandiría con al menos 100 líneas más de variables y métodos para obtener las propinas. Al usar la funcionalidad JSF incorporada, mi tiempo y preciosas líneas de código se ahorran.

Solo mis 2 centavos con respecto a esto, incluso con la pregunta ya marcada como respondida.

Answer 6

Me gusta probar el código comercial sin View, por lo que considero BackingBeans como interfaces desde el código de Ver a modelo. Nunca pongo ninguna regla o proceso en un BackingBean. Ese código va a Servicios o Ayudantes, lo que permite la reutilización.

Si utiliza validadores, colóquelos de su BackingBean y consúltelos desde su método de validación.

Si accede a los DAO para llenar Selects, Radios, Checkboxes, hágalo siempre desde un BackingBean.

¡Créanme !. Puede inyectar un JavaBean en un BackingBean, pero intente inyectar un BackingBean en otro. Pronto se encontrará en una pesadilla de código de mantenimiento y comprensión.