Understanding JSF as a MVC framework

Question

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.

Eclectic

Answer 1

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)

Risteau

With thar approach, in Spring MVC the controller -or Front Controller- is the DispatcherServlet and Spring Controllers are part of the Model. Sounds weird :S – Apocynthion

Made it a bit clearer, however I thought backing bean was just a "dataholder" for the view components and the managed beans was more like the controller you say backing beans are, am I wrong? – Eclectic

As a plumbing component, the backing bean is typically injected with a Service from which it obtains one or more entities. These entities are indeed hold on to. Via a getter the entity in its entirety is returned. View components bind to the individual properties of an entity. Basically the backing beans means the Service code stays 'pure' and data is cached during the scope of the bean (often view scope or request scope). – Risteau

I will add that if we build properly our EJBs and JPAs (Model) we can then use WebServices as another type of View components. – Ascomycete

@RodmarConde well, a bit perhaps, but more often some client-side code is seen as the view in that case and the web service is simply a path to the service. – Risteau

@ArjanTijms The answer you given is like a head shot, easy to get the exact point. – Univalve

The link you provided is dead : sts.tu-harburg.de/pw-and-m-theses/2007/maab07.pdf – Kaffraria

@MarcBouvier you may find this helpful tutorialspoint.com/jsf/jsf_architecture.htm – Bakehouse

Answer 2

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.

Claque

What is the difference between Java Beans and Managed Beans? – Rabe

Hi @KorayTugay Java Beans are simple classes with getters and setters and a default constructor, while a Managed Bean is is a lightweight container-managed object. Java Beans: en.wikipedia.org/wiki/JavaBean/index.html Managed Beans: docs.oracle.com/javaee/6/tutorial/doc/gjaam.html#gjacb – Claque

Thanks, the above answer BOLDLY states that a managed bean is not a controller.. So it is a little confusing really. – Rabe

And if possible, can you explain in simple english what you mean by "using for persistence" ? – Rabe

Let's imagine you'll work with a persistence layer, then you should define your own model classes, whatever it be (ORM solution or even JDBC). Let's assume you chose JDBC and you'll have classes like "Person.java" for example with a name and age as attributes. Before persisting you'll have to set it's values (a name, age, etc). This will normally be known as an "entity" or model for general purpose. If you choose an ORM solution like (Hibernate) you should map your class, using annotations (@Entity) or a XML file. Hope you get the idea, this is a quite superficial explaining for sure. – Claque

Answer 3

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.

Suez

Answer 4

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.

Hatred