title: Making Distinctions Between Different Kinds of JSF Managed-Beans
body: <p>I recently read this article from Neil Griffin <a href="http://java.dzone.com/articles/making-distinctions-between">Making Distinctions Between Different Kinds of JSF Managed-Beans</a> and it got me thinking about the distinction between different beans in my own application. To quickly summarise the gist:</p>
  
  <blockquote>
    <ul>
    <li><p>Model Managed-Bean: This type of managed-bean participates in the
    "Model" concern of the MVC design pattern. When you see the word
    "model" -- think DATA. A JSF model-bean should be a POJO that follows
    the JavaBean design pattern with getters/setters encapsulating
    properties.</p></li>
    <li><p>Backing Managed-Bean: This type of managed-bean participates in the
    "View" concern of the MVC design pattern. The purpose of a
    backing-bean is to support UI logic, and has a 1::1 relationship with
    a JSF view, or a JSF form in a Facelet composition. Although it
    typically has JavaBean-style properties with associated
    getters/setters, these are properties of the View -- not of the
    underlying application data model. JSF backing-beans may also have JSF
    actionListener and valueChangeListener methods.</p></li>
    <li><p>Controller Managed-Bean: This type of managed-bean participates in
    the "Controller" concern of the MVC design pattern. The purpose of a
    controller bean is to execute some kind of business logic and return a
    navigation outcome to the JSF navigation-handler. JSF controller-beans
    typically have JSF action methods (and not actionListener methods).</p></li>
    <li><p>Support Managed-Bean: This type of bean "supports" one or more views
    in the "View" concern of the MVC design pattern. The typical use case
    is supplying an ArrayList to JSF h:selectOneMenu drop-down
    lists that appear in more than one JSF view. If the data in the
    dropdown lists is particular to the user, then the bean would be kept
    in session scope.</p></li>
    <li><p>Utility Managed-Bean: This type of bean provides some type of
    "utility" function to one or more JSF views. A good example of this
    might be a FileUpload bean that can be reused in multiple web
    applications.</p></li>
    </ul>
  </blockquote>
  
  <p>This made sense to me and for the past few hours I have been refactoring my code and came up with the following with respect to the user login:</p>
  
  <p>The <code>AuthenticationController</code> is an example of a Controller Managed-Bean. It is request-scoped and features two getters and setters for setting a username and password, and two navigation methods, <code>authenticate</code> and <code>logout</code>, navigating the user to either their private area upon successful login, or back to the main page when logging out.</p>
  
  <p>The <code>UserBean</code> is an example of a Support Managed-Bean. It is session-scoped and features an instance of <code>User</code> class (which would be null when you are not authenticated) with a getter and setter, nothing more.</p>
  
  <p>The <code>AuthenticationController</code> has this user as a managed property (<code>@ManagedProperty(value = "#{userController.user} private User user;</code>). Upon successful authentication, the <code>AuthenticationController</code> would set the managed property to the actual user instance with the corresponding username that was used for the login.</p>
  
  <p>Any new beans would be able to grab the user as a managed property as well and pull the data they need, such as group membership for instance, if the <code>User</code> class would feature a list with group names.</p>
  
  <p>Would this way be the proper way to go about with regard to the seperation of concerns?</p>