verdes vainas tipos significado semillas que llama judias comestibles java jsf java-ee backing-beans

java - vainas - Haciendo distinciones entre diferentes tipos de judías administradas JSF



tipos de vainas de semillas (1)

Esta es una pregunta muy subjetiva. Personalmente estoy en desacuerdo con ese artículo y encuentro que está dando un muy mal consejo a los principiantes.

Modelo Managed-Bean: este tipo de beans administrados participa del interés "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.

Definitivamente no lo haría o lo llamaría un frijol administrado. Simplemente conviértalo en propiedad de @ManagedBean . Por ejemplo, un DTO o JPA @Entity .

Backing Managed-Bean: este tipo de beans administrados 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.

De esta forma, sigues duplicando y mapeando las propiedades de la entidad en el bean gestionado. Esto no tiene ningún sentido para mí. Como se dijo, simplemente convierta a la entidad en una propiedad del bean administrado y deje que los campos de entrada lo refieran directamente como #{authenticator.user.name} lugar de #{authenticator.username} .

Controlador Managed-Bean: este tipo de beans administrados 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).

Esto describe la clase @RequestScoped / @ViewScoped prácticamente. Si los métodos de escucha de eventos están permitidos o no depende de si son específicos de la vista que está vinculada al bean y / o si su trabajo depende del estado del bean. Si lo son, entonces pertenecen al frijol. Si no, entonces deberían ser una implementación independiente de cualquier interfaz FacesListener , pero definitivamente no es un bean administrado.

Soporte Managed-Bean: 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.

Multa. Para datos de toda la aplicación, como listas desplegables, simplemente use un bean @ApplicationScoped y para los datos de toda la sesión, como el usuario que ha iniciado sesión y sus preferencias solo use una @SessionScoped .

Utility Managed-Bean: 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.

Esto realmente no tiene sentido para mí. Los respaldos generalmente están vinculados a vistas únicas. Esto se parece demasiado a una implementación de ActionListener que va a ser utilizada por <f:actionListener> en componentes de comando a su elección. Definitivamente no es un frijol manejado.

Para ejemplos de arranque del enfoque correcto, vea también:

Recientemente leí este artículo de Neil Griffin Making Distinctions Between Different Kinds of JSF Managed-Beans y me hizo pensar en la distinción entre diferentes beans en mi propia aplicación. Para resumir rápidamente la esencia:

  • Modelo Managed-Bean: este tipo de beans administrados participa del interés "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.

  • Backing Managed-Bean: este tipo de beans administrados 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: este tipo de beans administrados 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: 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.

  • Utility Managed-Bean: 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.

Esto tuvo sentido para mí y durante las últimas horas he estado refacturando mi código y se me ocurrió lo siguiente con respecto al inicio de sesión del usuario:

AuthenticationController es un ejemplo de Controller Managed-Bean. Tiene un alcance de solicitud y cuenta con dos getters y setters para configurar un nombre de usuario y contraseña, y dos métodos de navegación, authenticate y logout , navegar al usuario a su área privada al iniciar sesión exitosamente o regresar a la página principal al cerrar la sesión.

El UserBean es un ejemplo de un Support Managed-Bean. Tiene un ámbito de sesión y cuenta con una instancia de clase de User (que sería nula cuando no está autenticado) con un getter y un setter, nada más.

AuthenticationController tiene este usuario como una propiedad administrada ( @ManagedProperty(value = "#{userController.user} private User user; ). Tras la autenticación exitosa, AuthenticationController establecería la propiedad administrada a la instancia de usuario real con el nombre de usuario correspondiente que era utilizado para el inicio de sesión.

Todos los beans nuevos podrían atrapar al usuario como una propiedad administrada también y extraer los datos que necesitan, como la pertenencia a un grupo, por ejemplo, si la clase User tuviera una lista con nombres de grupos.

¿Estaría de esta manera la forma correcta de proceder con respecto a la separación de preocupaciones?