JSF backing bean structure (mejores prácticas)

Gran pregunta. Sufrí mucho con el mismo dilema cuando me mudé a JSF. Realmente depende de su aplicación. Soy del mundo de Java EE, así que recomendaría tener la menor lógica de negocios en sus frijoles de respaldo como sea posible. Si la lógica está puramente relacionada con la presentación de su página, entonces está bien tenerlo en el frijol de respaldo.

Creo que una de las (muchas) fortalezas de JSF es en realidad el hecho de que puede exponer objetos de dominio directamente en los frijoles administrados. Me por lo tanto, recomendaría encarecidamente el enfoque <:outputText value="#{myBean.anObject.anObjectProperty}" />, de lo contrario, terminará haciendo demasiado trabajo para sí mismo al exponer manualmente cada propiedad. Además, sería un poco complicado al insertar o actualizar datos si encapsulara 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 frijol.

EDITAR: En realidad, si va a encapsular cada propiedad de objeto que desea exponer, le recomendaría que en su lugar vincule los componentes de la interfaz de usuario 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é con fuerza todo lo que sabía sobre la creación de aplicaciones web y comencé a tratarlo como una aplicación GUI en su lugar. JSF imita mucho Swing y, por lo tanto, las mejores prácticas para desarrollar aplicaciones Swing también se aplicarían principalmente a creación de aplicaciones JSF.

Puede que no responda a todas sus preguntas, porque pocas parecen bastante dependientes de caso a caso.

• Esto está bien para tener una lógica de negocios en su frijol de respaldo. Depende de dónde vienen. Si está practicando el diseño impulsado por el dominio, se sentirá tentado a incluir la lógica de negocios en el respaldo de bean o también puede ser lógica de persistencia. Argumentan que por qué tan tonto objeto. El objeto debe llevar no solo el estado sino también el comportamiento. Por otro lado si consideras tradicional Java EE forma de hacer las cosas, es posible que tenga ganas de tener datos en su frijol de respaldo, que también puede ser su frijol entidad, y otros negocios y lógica de persistencia en algún frijol de sesión o algo así. Eso también está bien.

• Está perfectamente bien tener un solo frijol 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 usted es tener en la mano. Preferiría ir dominio conducido aquí, podría ser apropiado agregar propiedades a la existente o de lo contrario crear un nuevo frijol para eso. El que mejor se adapte. No creo que haya una bala de plata para esto.

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

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

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

1. El frijol se volvería muy grande eventualmente
2. Es más fácil para otras personas encontrar lo que están buscando si están resolviendo problemas en la página de inicio de sesión, si luego pueden buscar fácilmente el código de inicio de sesión.archivo java.
3. A veces tienes pequeños trozos de funcionalidad que es claramente distinta del resto de su código, al separar esto, me imagino que le haría más fácil a usted mismo volver a desarrollar/expandir este código en algo más grande, cuando ya tiene un buen frijol con buena estructura.
4. Tener 1 big bean, para hacerlo todo, lo hará más dependiente de la memoria si / cuando tienes que hacer declaraciones como esta MyBigBean bigBean = new MyBigBean (); en lugar de usar la funksjonality que realmente necesitabas haciendo loginBean loginBean = new loginBean (); (Corrígeme si estoy equivocado aquí???)
5. En mi opinión, separar tus frijoles es como separar tus métodos. Usted no quiere 1 método grande que se ejecuta más de 100 de líneas, sino más bien dividirlo con nuevos métodos que maneja 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 JSF.

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

No sería necesario mantener solo un frijol de respaldo por página. Depende de la funcionalidad, pero la mayoría de las veces tenía un frijol 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 (enlazaré con RegisterBean) y un enlace de cesta de la compra (ShoopingBasketBean).

Utilizo este <:outputtext> ya que normalmente sigo respaldando beans como action beans que contiene un objeto de datos. No quiero escribir una wrapper en mi bean de respaldo para acceder a las propiedades de mis objetos de datos.

Me gusta probar código de negocio sin Vista, por lo que considero BackingBeans como interfaces desde la Vista hasta el código del modelo. Nunca puse ninguna regla o proceso en un fondo. Ese código va a Servicios o Helpers, permitiendo su reutilización.

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

Si accede a DAOs para rellenar Selects, Radios, Checkboxes, hágalo siempre desde un BackingBean.

Créeme!. Usted puede inyectar un JavaBean en un BackingBean, pero intenta inyectar un BackingBean en otro. Pronto estará en un nigntmare de mantenimiento y comprensión de código.