Contradictory explanations of MVC in JSF

Question

I'd starting to learn JSF, but first I'd like to understand the big picture of it as an MVC framework.

There are several answers with many upvotes explaining what are MVC layers in JSF, but they usually contradict themselves.

BalusC's answer: What components are MVC in JSF MVC framework?

In the big architectural picture, your own JSF code is the V:

M - Business domain/Service layer (e.g. EJB/JPA/DAO)
V - Your JSF code
C - FacesServlet

In the developer picture, the architectural V is in turn dividable as below:

M - Entity
V - Facelets/JSP page
C - Managed bean

Jigar Joshi's answer in the same thread:

M odel would be your ManagedBean

V iew would be jsp,XHTML (well you can accommodate various views here )

C ontroller will be FacesServlet

Here, another view on the problem:

In JSF you don't implement a controller. Consequently, a backing bean or any other kind of managed bean is NOT the controller.

Yet another, not from Stackoverflow this time:

In JSF, the master Controller is always the FacesServlet. Sub-Controllers are incorporated into the various control element tag implementations. You almost never write controller code in JSF, because it's all pre-supplied. So you only have to supply the View templates (xhtml) and the Models (backing beans).

A lot of people think that the action logic in backing beans makes them Controllers. This is incorrect. A Controller is a component whose sole purpose in life is to synchronize the Model and View. In JSF, that task is performed by the FacesServlet and the controls. You may have Validators and Converters performing adjunct functions, but the actual synchronization (updating) is part of the JSF core.

I know MVC has many variants depending on if it's a desktop application, web aplication etc. so it's difficult to define MVC (try to find two sources with identical explanation of MVC).

I'm mostly concerned with Managed beans here. Are they M or C? Managed beans are apparently used to retrieve data from Model layer (the Model layer on the highest level of abstraction - big architectural picture as in BalusC's answer, that is EJB, JPA and DAO) and store the result to be used by the view. Controller layer in MVC is the one responsible for handling commands from the view, communicating with model layer and retrieving data from the model layer. Is managed bean used to communicate with Model layer? Yes, and it also makes the retrieved data available for the view. For me it belongs to controller layer, not a model, because it doesn't contain logic used to retrieve the data, or the data itself, but only calls the appropriate model layer methods (take a look at BalusC's code sample).

So what's the source of my confusion? Could anyone explain this once and for all so that it's clear for beginners in JSF?

Possession

MVC can be interpreted in different ways and might depend on the use case/point of view. As an example, from a rendering point of view M = Managed Bean (data), V = Page (view), C = FacesServlet (controller for rendering) while from an application point of view you could say M = application model, e.g. EJBs + Entities, V = page, C = Managed Bean which mediates between model and view. - In effect you could even apply MVC at a system level and above, e.g. M = database, V = user interface, C = application logic. – Blitzkrieg

I think the main problem comes from the fact that MVC does not have a clear-cut definition: there are multiple ways of doing MVC and every citation you made is true depending on the context. – Lubric

@Blitzkrieg notice that you've provided 2 answers, based on two different points of view, and none of them agrees with any of the answer I've linked to! – Possession

That's what I wanted to point out: if you have different points of view you'll get different answers and mappings. – Blitzkrieg

The point of view, in this case, would be the "Web application" point of view. Then MVC refers to the Web/Presentación layer. So V is for the page, C is for the FacesServlet, and M is for the data managed in the Web layer. Regarding M: It could be entities from the bussines layer or pure presentation data, like for example two Integer attributes in the backing bean which define a search interval on an bussines entity bean field in a search page. – Hubie

Jigar Joshi's answer is wrong. The controller is the part that joins the model to the view. That encompasses practically all of JSF, including EL, CDI, the FacesContext, .... – Rothschild

By they way, is my understanding of MVC okay, based on the last two paragraphs? – Possession

In real programming (in few/ every envinronmets from web to desktop) the only clear part is View. C&M have mixed parts. At theoretical level: so MVC patter involve to the next MVCC etc ... (sorry for no spelling) Agree with @Blitzkrieg – Celloidin

M = Entities, C = Beans (i.e manipulate M using EJBs), V = Facelets (refers to C for Controlled/Controllable Views). Very simple. Don't make it complicate. – Parlance

Answer 1

I'm mostly concerned about Managed beans here. Are they M or C?

People consider them M when they look like this:

@ManagedBean
public class Bean {

    private String username; // +getter+setter
    private String password; // +getter+setter

    @Resource
    private DataSource dataSource;

    public void login() {
        try (
            Connection connection = dataSource.getConnection();
            PreparedStatement statement = connection.prepareStatement("SELECT * FROM User WHERE username = ? AND password = MD5(?)");
        ) {
            statement.setString(1, username);
            statement.setString(2, password);

            try (ResultSet resultSet = statement.executeQuery()) {
                if (resultSet.next()) {
                    // Login.
                }
            }
        }
    }

    // ...
}

But people consider them C when they look like this:

@ManagedBean
public class Bean {

    private User user // +getter

    @EJB
    private UserService userService;

    public void login() {
        if (userService.find(user) != null) {
            // Login.
        }
    }

    // ...
}

This is also mentioned in the very same MVC answer you found:

Note that some starters and even some —very basic— tutorials mingle/copy/flatten the entity's properties in the managed bean, which would effectively make the controller a model. Needless to say that this is poor design (i.e. not a clean MVC design).

See also:

• Our JSF wiki page

Watercress

So it's better for managed beans to be controllers. Erm, what do you mean by flattening entity's properties? Is it your first code sample? Probably the user has username and password properties, but instead of keeping the user, the properties are extracted and stored as fields? But anyway, what about this quote: 'A lot of people think that the action logic in backing beans makes them Controllers. This is incorrect.'. Is it just wrong? – Possession

Flattening is adding delegating getters to bean like public String getUsername() { return user.getName(); } and using #{bean.username} instead of #{bean.user.name}. As to the quote, that's technically indeed correct. – Watercress

In a true MVC approach, is it always desirable or expected to create new Entity() (somewhere like @PostConstruct or at its declaration place) while performing "Create" (INSERT) out of CRUD instead of declaring individual properties of Entity in a managed bean? – Primm

@Tiny: Yes. Some people even make the Entity a @Model so it can simply be @Injected. – Watercress

@Primm In my very personal opinion, there is not such a thing as a true MVC approach, as long as the algorithms satisfy your requirements. In my approach, I use beans as temporary stores for new and already persisted entities which can be controlled using injected JPA related EJBs (façades). Beans are the controllers, wherever the entity classes are the M part of the architecture. EJBs are also part of the sub-controller system in my opinion. Facelets are the interface between the controllers and the rendered HTML view, and which form the V part of the so-called MVC approach in JSF. – Parlance

@SJan : I was only interested in a practical approach whether it is a good idea to set the properties of an entity directly instead of declaring individual corresponding properties in a managed bean. Terminologies may of course vary greatly depending upon where are being used. I am very less concerned with linguistic term usages. – Primm

@Primm You don't need to initialize an entity in a @PostConstruct method, you can do it up on an ajax event by example, it will save you some space & time depending on your case. My point is that it always depends on your very own case. – Parlance

@Possession Yes I meant managed beans. But both beans and EJBs form the controller (C) sub-system. – Parlance

@SJan EJB contains business domain logic, and this is exactly what model layer is responsible for. I'd say EJB are the model actually. – Possession

@Possession Well, as per my very own definition, EJBs are glue between controllers and models, in fact, they belong to both (they get injected into C and mainly do CRUD operations using M). In a simplistic view, Entities form M, Beans form C, Facelets form V. Between M & C, you have EJBs (and/or filters, converters, etc), and between C & V you have EL (and/or filters, ajax listeners, etc). – Parlance