java - showcase - Estructura de beans de respaldo de JSF(mejores prácticas)

primefaces

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 respaldos.

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 del acoplamiento entre la página JSF y el bean de respaldo, nunca dejo que la página JSF acceda a las propiedades de ninguna propiedad de backing bean. Por ejemplo, nunca permití algo como:

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

Siempre requiero algo como:

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

con un valor de bean de respaldo de:

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

Cuando recorro una colección, utilizo una clase contenedora para evitar profundizar en un objeto en una tabla de datos, por ejemplo.

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

Answer 1

Creo que lo más importante con sus respaldos es separar sus lógicas. Si tiene una página principal para un sistema CMS, vería que es una mala práctica poner cada código en un solo frijol porque:

1. El grano se volvería muy grande eventualmente
2. Es más fácil para otras personas encontrar lo que buscan 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 tienes pequeñas funciones que son claramente distintas del resto de tu código, al separar esto, imagino que harías que sea más fácil para ti mismo rediseñar / expandir este código en algo más grande, cuando ya tienes un buen grano con buen estructura.
4. Tener 1 gran 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 equivocado aquí?)
5. En mi opinión, separar tus granos es como separar tus 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, lo más probable es que alguien que no sea usted también tenga que trabajar en sus proyectos de JSF.

En cuanto al acoplamiento, no creo que sea un problema molesto permitir que las páginas JSF accedan también a las propiedades de los objetos de su forjado. 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 2

Es posible que desee comprobar esto: hacer distinciones entre diferentes tipos de beans administrados JSF .

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

• Modelo Managed-Bean : normalmente alcance de la sesión. Este tipo de frijol administrado participa en la preocupación "Modelo" del patrón de diseño de 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 solicita alcance. Este tipo de frijol administrado 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 Managed-Bean : normalmente solicita alcance. Este tipo de frijol administrado participa en la preocupación "Controlador" del patrón de diseño de 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 sesión o alcance de 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 : normalmente ámbito de aplicación. 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 3

Gran 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 <:outputText value="#{myBean.anObject.anObjectProperty}" /> , de lo contrario terminará haciendo demasiado trabajo para exponer cada propiedad manualmente. 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 recomendaría que en su lugar vincule los componentes UI al bean de respaldo y luego inyecte el contenido directamente en el valor del componente.

En términos de estructura de frijol, 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 4

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

Si usa validadores, colóquelos de su BackingBean y haga referencia a ellos desde su método de validación.

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

¡Créame!. 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.

Answer 5

No sería necesario mantener solo un grano 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).

Utilizo este <: outputText value = "# {myBean.anObject.anObjectProperty}" /> ya que 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 6

Puede que no responda todas tus preguntas, porque pocas parecen depender de cada caso.

• Esto está bien para tener una lógica comercial 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 solo 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 es mucho más dependiente del caso que tenga a mano. 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 el ejemplo del código dado, no veo ningún gran beneficio.