Part of the reason why it’s often not entirely clear in JSF and many other web frameworks which parts of it correspond to which part of MVC, is that the MVC pattern was originally devised for desktop applications.
In a desktop application, the nodes M, V and C are a maximum connected graph, meaning each part can communicate with every other part. E.g. if the model changes, it can push this change to the view. This is particularly visible in case there are multiple representations of the view in a desktop application. Change one, and see the other update in real-time.
Due to the client/server and request/response nature of web applications, classic MVC doesn’t map 1:1 to most web frameworks.
Specifically, in JSF the mapping is as follows:
- Model – The Services/DAOs plus the entities they produce and consume. The entry point to this is the managed bean, but in Java EE (of which JSF is a part) these artifacts are typically implemented by EJB and JPA respectively.
- View – The UI components and their composition into a full page. This is fully in the domain of JSF and implemented by JSF
UIComponents and Facelets respectively. - Controller – The traffic cop that handles commands and incoming data from the user, routes this to the right parts and selects a view for display. In JSF one doesn’t write this controller, but it’s already provided by the framework (it’s the
FacesServlet).
Especially the last part is frequently not well understood: In JSF you don’t implement a controller. Consequently, a backing bean or any other kind of managed bean is NOT the controller.
The first part (the model) is also not always clearly understood. Business logic may be implemented by EJB and JPA, but from the point of view of JSF everything that is referenced by a value binding is the model. This is also where the name of one of the JSF life-cycle phases comes from: Update Model. In this phase JSF pushes data from the UI components into the model. In that sense, (JSF) managed beans are thus the model.
Although JSF itself doesn’t explicitly define the concept, there is an often recurring and specific usage of managed beans called the backing bean.
For JSF a backing bean is still the model, but practically it’s a plumbing element that sits in the middle of the Model, View and Controller. Because it performs some tasks that may be seen as some controller tasks, this is often mistaken to be the controller. But, as explained before this is not correct. It can also perform some model tasks and occasionally do some view logic as well.
See also: