Understanding JSF as a MVC framework

I am reading on JSF and I feel rather confused why JSF is a MVC framework (or atleast which parts belongs to which "letter").

I looked at this question: What components are MVC in JSF MVC framework?

I read there if you don't look at it in an aggregated view the model is your entity, view is your XHTML code and controller is the managed bean. Hmm...Ok, but doesn't the view very often depend on carrying out further business logic calls which returns a set of entities for example, does the description still fit?

One book I read described it as managed beans is the some kind of "message" bringer that the Faces Servlet (Controller) use to invoke the business layer (Model) and then the XHTML code is the view.

There are so many explanations and differences so I don't know which or how to understand it.

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:

• What are the main advantages of MVC pattern over the old fashioned 3-layer pattern
• MVC-Architecture of JavaServer Faces (Chapter 4.3)

In a minimalist form, it's:

• Model: Anything you use for persistence (Hibernate, JPA, etc) and data modeling (Java Beans).
• View: xhtml, jsp, etc.
• Controller: Mananaged Beans.

JSF gives you the power to control your requests/responses. The way you create model/view it's not directly connected to the framework MVC concept. It's just a matter of choice. The MVC concept is related to code organization.

Analogously Struts is a MVC framework, but it works mainly as a controller.

I think I help you to better clarify your idea.

The interesting thing about the managed bean idea is that it can both be used as a model (MVC pattern) or as a controller (mediating-controller MVC pattern, also called model-view-adapter), where the model and view do not interact directly.

In that latter case, the routing mechanism is not the controller, as the business logic is contained in the managed bean and the Model is strictly a domain model. We then have:

• Model - contains the domain model, in most cases represents the tables in the database, persisted through DAOs.

• View - the ui components, connected to the bean;

• Controller - the managed bean that contains the business logic and handles communication between the view and the model.

I think some people confuse mediating-controller MVC as plain MVC, which leads to the different explanations encountered.

I think, all anwsers here are correct. But the main point for confusion arises for me from mixing the mvc components' definitions coming from the framework, here JSF, with those model and controller components you define in your application design:

Assume you change from JSF to any other Web UI framework in your business application: You will still have a "business model" and a "business controller". (In our projects we just call these components "the model" and "the process".) What does this mean: Either you can't use mvc for the description of the overall application architecture, but solely for the UI, or you may have to accept many controller, model like components in your full application stack.