Where's managed bean on MVC?

[Rafael Fontoura]

Well, since I started to work with Struts 1 long time ago, I leared that the Action class (don't remember the full qualified name of Struts base class) were the C of MVC design pattern. After that, about 2 or 3 years after that (4 or 5 years ago) I found a substitute to it using JSF: the Managed Bean (MB), that time called backing bean.

Since I've been reading the posts on this forum I saw people naming the packages of the MBs or the MBs with 'controller' suffix and think this were OK, until members of this forum correcting people saying that today the MB has a few or nothing to do with controller, and it is a model (M of MVC). After reading a few articles of MVC, the main thing that makes me believe on this is that when the model changes, the view see this change whithout controller intercepting these communication, and the model classes I write don't do this, but the MB I write does.

Here's an excerpt taken from Head First Design Patterns book explaining the roles of MVC components:
- VIEW - gives you a presentation of the model. The view usually gets the state and data it needs to display directly from the model.
- CONTROLLER - takes user input and figures out what it means to the model.
- MODEL - holds the data, state and application logic. The model is the oblivious to the view and controller although it provides an interface to manipulate and retrieve its state and it can send notifications of state changes to observers.

On the next web system I'm gonna work I want to split the classes and components on the following way:
- xhtml pages - has presentation components and reference to managed beans
- view beans - not a managed bean, just a POJO, keep instance classes used on xhtml pages, like lists, entity beans (I'm using JPA to map DBMS tables to Java) and help attributes and classes
- service classes - holds the business logic, do the validation after the user interacts with the page and communicate with classes that manage the entities (DAOs), retrieving data and sending data do persist on DBMS.
- managed beans - @ManagedBean annotated, has reference to the view beans and the service classes, being the first Java class to receive the action fired by the user, sending content to the service classes (retrieved by the view bean). Here the managed bean would do almost nothing but changing the application flow: it decides when to call a service class, to return to a page (return String = xhtml, presentation view) or to send content processed by a Report tool to the page (a PDF created by JasperReports, for example)

The way I write managed beans makes it more 'controller' than 'model' to me. After viewing this page, which explains that there's many kind of managed beans (model, backing bean, support, utillity), I became a bit confused.

The real question I want to be answered is: the Managed Bean will always be a non-controller component or it depends on the context?

Thanks in advance and sorry for my bad english.

[Tim Holloway]

In JSF:

The View is the xhtml template, or its equivalent.
The Controllers are the FaceletsServlet and the control code in the individual JSF control elements.
The Model is the JSF backing bean.

Very rarely in JSF do you write controller code. Most of the controllers are pre-supplied ready to go out of the box. Backing beans are NOT controllers. At best, they may supply a tiny amount of controller-like logic, but in a well-architected app, usually not. The closest thing to Controller code most people will produce are Converters.

The Backing Bean is a slightly impure beast. One thing that classical MVC never addresses is how you get from the MVC display environment into the general business processing environment that sets up the model and captures changes made to it. In JSF, the primary mechanism for this are user-supplied POJO methods that can be called prior to display of the model and action methods that are called when a View SUBMIT control is fired off. ActionListeners can also do this, but should be reserved for situations where a pojo Action method isn't sufficient.

There are also some other listeners that can tie to a backing bean. Most commonly used are the valueChangeListeners, which in a dim light could be considered Controller functions. However, unlike a true Controller, the valueChangeListener will only fire if the controls agree that all submitted inputs are value, and the data transfer is limited - the valueChangeListener doesn't attach to the View. Instead, the listener gets data fed to it. Also, the listener only operates on the view-to-model part of the MVC system. A true Controller would also be able to to model-to-view transfers and the closest that valueChangeListeners can do in that regard is to make changes that update the Model so that when the View is next output, they will be part of the updated View.