Espero que en esta publicación pueda obtener las opiniones de la gente sobre las mejores prácticas para la interfaz entre las páginas JSF y los beans de respaldo.
Una cosa con la que nunca puedo conformarme 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é frijoles de respaldo? ¿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 tener un solo bean de respaldo para toda la página, considerando la complejidad que implica inyectar un bean en otro? ¿Debería el bean de respaldo contener alguna lógica empresarial real o debería contener estrictamente datos?
No dude en responder estas preguntas y otras que puedan surgir.
En cuanto a reducir el acoplamiento entre la página JSF y el bean de respaldo, nunca permito que la página JSF acceda a las propiedades de ninguna propiedad del bean de respaldo. Por ejemplo, nunca permito algo como:
<h:outputText value="#{myBean.anObject.anObjectProperty}" />Siempre requiero algo como:
<h:outputText value="#{myBean.theObjectProperty}" />con un valor de frijol de respaldo de:
public String getTheObjectProperty()
{
return anObject.getAnObjectProperty();
}
Cuando recorro una colección, uso 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.
Respuestas:
Es posible que desee verificar esto: hacer distinciones entre diferentes tipos de beans administrados por JSF .
Aquí hay una descripción de los diferentes tipos de frijoles, tal como los define Neil Griffin en el artículo anterior:
fuente
Gran pregunta. Sufrí mucho con el mismo dilema cuando me mudé a JSF. Realmente depende de tu aplicación. Soy del mundo Java EE, por lo que recomendaría tener la menor lógica comercial posible en sus beans 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 una de las (muchas) fortalezas de JSF es en realidad el hecho de que puede exponer objetos de dominio directamente en los beans administrados. Por lo tanto, recomendaría encarecidamente el
<:outputText value="#{myBean.anObject.anObjectProperty}" />enfoque, de lo contrario, terminará haciendo demasiado trabajo al exponer manualmente cada propiedad. Además, sería un poco complicado 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 bean.EDITAR: En realidad, si va a encapsular todas las propiedades del 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 bean, el punto de inflexión para mí fue cuando ignoré a 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.
fuente
Creo que lo más importante con sus frijoles de respaldo es separar sus lógicas. Si tiene una página principal para un sistema CMS, vería como una mala práctica poner cada fragmento de código en un bean porque:
En cuanto al acoplamiento, no lo veo como un problema problemático permitir que sus páginas JSF accedan también a las propiedades de los objetos en su backingbean. Este es un soporte que está integrado en JSF, y realmente hace que sea más fácil de leer y construir imo. Ya está separando estrictamente la lógica MVC. Al hacer esto, te ahorras toneladas de líneas con getters y setters en tu backingbean. Por ejemplo, tengo un objeto realmente enorme que me dieron los servicios web, 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 propiedades. Al utilizar la funcionalidad JSF incorporada, se ahorra tiempo y valiosas líneas de código.
Solo mis 2 centavos con respecto a esto, incluso con la pregunta ya marcada como respondida.
fuente
Puede que no responda a todas sus preguntas, porque pocas parecen depender de un caso a otro.
Está bien tener una lógica empresarial en su bean de respaldo. Depende de dónde vengas. Si está practicando el diseño impulsado por dominios, tendrá la tentación de incluir la lógica empresarial en el bean de respaldo o también puede ser lógica de persistencia. Ellos argumentan que por qué objetar tan tonto. El objeto no solo debe contener estado, sino también comportamiento. Por otro lado, si considera la forma tradicional de hacer las cosas de Java EE, es posible que tenga ganas de tener datos en su bean de respaldo, que también puede ser su bean de entidad, y otra lógica empresarial y de 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. Puede que esto no parezca correcto, pero depende del caso.
Su otra pregunta depende mucho más del caso que tenga entre manos. Preferiría ir controlado por dominio aquí, podría ser apropiado agregar propiedades al existente o crear un nuevo bean para eso. Cual siempre se adapta mejor. No creo que haya una fórmula mágica para esto.
Qué propiedades pertenecen a qué bean de respaldo. Bueno, ¿no depende del objeto de dominio? O puede ser que la pregunta no sea tan clara.
Además, en su ejemplo de código dado, no veo ningún beneficio enorme.
fuente
No es necesario que mantenga solo un bean de respaldo por página. Depende de la funcionalidad, pero la mayoría de las veces tenía 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 (vincularé con RegisterBean) y un enlace de cesta de la compra (ShoopingBasketBean).
Yo uso este <: outputText value = "# {myBean.anObject.anObjectProperty}" /> ya que normalmente sigo respaldando 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.
fuente
Me gusta probar el código comercial sin View, por lo que considero BackingBeans como interfaces desde el código de View a Model. Nunca coloco ninguna regla o proceso en un BackingBean. Ese código entra en Servicios o Ayudantes, lo que permite su reutilización.
Si usa validadores, elimínelos de su BackingBean y haga referencia a ellos desde su método de validación.
Si accede a los DAO para completar selecciones, radios, casillas de verificación, hágalo siempre desde un BackingBean.
¡Créame!. Puede inyectar un JavaBean en un BackingBean, pero intente inyectar un BackingBean en otro. Pronto estará en una nigntmare de mantenimiento y comprensión del código.
fuente