J'ai récemment lu cet article de Neil Griffin. Distinctions entre les différents types de Managed-Beans JSF et cela m'a fait réfléchir à la distinction entre les différents beans dans ma propre application. Pour résumer rapidement l'essentiel :
Modèle Managed-Bean : Ce type de Managed-Bean participe à la co-création de "Modèle" du modèle de conception MVC. Quand vous voyez le mot "modèle", pensez à DATA. Un JSF model-bean doit être un POJO qui suit le modèle de conception JavaBean avec des getters/setters. le modèle JavaBean avec des getters/setters encapsulant les propriétés. les propriétés.
Backing Managed-Bean : Ce type de managed-bean participe à la préoccupation "Vue" du modèle de conception MVC. L'objectif d'un backing-bean est de prendre en charge la logique de l'interface utilisateur, et il a une relation 1::1 avec une vue JSF, ou un formulaire JSF dans une composition Facelet. Bien qu'il typiquement des propriétés de style JavaBean avec des associés, il s'agit de propriétés de la vue et non du modèle de données modèle de données de l'application sous-jacente. Les backing-beans JSF peuvent aussi avoir des propriétés JSF actionListener et valueChangeListener.
Contrôleur Managed-Bean : Ce type de managed-bean participe à la préoccupation "contrôleur" du modèle de conception MVC. L'objectif d'un contrôleur est d'exécuter un certain type de logique métier et de renvoyer un code de résultat de navigation au gestionnaire de navigation JSF. Les beans contrôleurs JSF ont généralement des méthodes d'action JSF (et non des méthodes actionListener).
Support Managed-Bean : Ce type de bean "supporte" une ou plusieurs vues dans la préoccupation "Vue" du modèle de conception MVC. Le cas d'utilisation typique est de fournir une ArrayList aux listes déroulantes JSF h:selectOneMenu. qui apparaissent dans plus d'une vue JSF. Si les données contenues dans les listes déroulantes sont particulières à l'utilisateur, alors le bean doit être gardé dans la portée de la session.
Utilitaire Managed-Bean : Ce type de bean fournit un certain type de fonction "utilitaire" à une ou plusieurs vues JSF. Un bon exemple de ceci d'un bean FileUpload qui peut être réutilisé dans plusieurs applications applications web.
Cela m'a semblé logique et, au cours des dernières heures, j'ai remanié mon code et j'ai trouvé ce qui suit en ce qui concerne la connexion de l'utilisateur :
El AuthenticationController est un exemple de Managed-Bean de contrôleur. Il s'agit d'une requête et il comporte deux getters et setters pour définir un nom d'utilisateur et un mot de passe, ainsi que deux méthodes de navigation, authenticate y logout qui permet à l'utilisateur d'accéder à sa zone privée lorsqu'il a réussi à se connecter, ou de revenir à la page principale lorsqu'il se déconnecte.
El UserBean est un exemple de Managed-Bean de soutien. Il est adapté à la session et comporte une instance de User (qui serait nulle si vous n'êtes pas authentifié) avec un getter et un setter, rien de plus.
El AuthenticationController a cet utilisateur comme propriété gérée ( @ManagedProperty(value = "#{userController.user} private User user; ). Une fois l'authentification réussie, le AuthenticationController définirait la propriété gérée sur l'instance réelle de l'utilisateur avec le nom d'utilisateur correspondant qui a été utilisé pour la connexion.
Tout nouveau haricot pourra également saisir l'utilisateur en tant que propriété gérée et extraire les données dont il a besoin, comme l'appartenance à un groupe par exemple, si la propriété de l'utilisateur est gérée. User La classe présenterait une liste avec les noms des groupes.
Serait-ce la bonne façon de procéder en ce qui concerne la séparation des préoccupations ?
