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.
