How does Servlet/JSP MVC patterns translate to JSF/Facelets (in particular the service and controller parts)?

Question

Let us take a basic example. In a servlet app I would have those classes:

• app.domain.User: domain or model POJO, would contain fields and getters/setters
• app.service.UserService: would contain methods that operate on User instances, such as Register(User). Would call the DAO.
• app.dao.UserDao: would be called by service to actually, say, insert a User in the DB.
• app.servlets.RegisterController: a servlet intercepting requests to www.app/registration and calling the methods in app.service.UserService. It would then redirect to WEB-INF\JSPs\registration.jsp which would take care of the view.

All this made perfect sense to me and clearly separated the concerns.

I have tried since to wrap my head around the JSF/Facelets way of thinking. I have went through many excellent resources here in SO and otherplaces but there is not any place that addresses this simple question - namely how does the dao/service/controller/view pattern translate into JSF.

To continue my example - I have set up a JSF project in eclipse, have translated my DB schema to "entities" and now I am left wondering - what kind of package, with what king of classes should I create to handle user Registration ? I understand I have to create xhtml pages for the view but where is the controller ?

Please do not point me to tutorials - I am aware of many, amongst which the @BalusC one - my problem is not to make this work but to understand the pattern. I have seen "session" packages containing "managed beans", "abstract facade" patterns etc etc but nothing that makes as clear sense as the good old servlets pattern.

So - among the "entities" created by the DB there is a User.java class that looks like the model to me. The view will be an xhtml. The controller ?

NB: this is not asking as so many duplicates here the differences between those technologies - I am asking about a clear translation of the very clear and intuitive controller/dao/service pattern to the JSF framework - or a clear statement that there is not such a translation.

See also:

• The NetBeans E-commerce Tutorial - bit outdated, actually uses JSP (!)
• An Eclipse / GlassFish / Java EE 6 Tutorial actually uses Servlets (!) but at least is eclipse based
• JSF 2.0 tutorial with Eclipse and Glassfish the BalusC one I referred to
• A school project featuring the servlet pattern and another bigger one with CDI
• Understanding JSF as a MVC framework

Answer 1

There are two levels of MVC in JSF 2:

• Model = @ManagedBean, View = Facelets/xhtml, Controller = FacesServlet if you look only at jsf
• Model = Entities + Services, Controller = @ManagedBean, View = xhtml if you look at your application at a whole.

The typical package layout in a JSF application is the same:

• com.foo.domain.featurex.service <- model
• com.foo.domain.featurex.model <- model
• com.foo.presentation.featurex <- controller
• xhtml files <- view

Not that big of a difference here except that your controller is now the FacesServlet (the heart of JSF) together with your @ManagedBean/@Named which would reside in a class like com.foo.presentation.featurex.Controller/Handler or something like that.

Example for a simple registration:

// we talk about the big picture here, not about how jsf is built 
// but how your app is built


// model
package com.foo.domain.registration.entity;

@Entity
public class User { 
    // fields
}

package com.foo.domain.registration.service;

// also model
@Stateless
public class RegistrationService {

    @PersistenceContext 
    EntityManager em;

    public void register(User u) { 
        em.persist(u);
    } 
}

package com.foo.presentation

// controller
@Named
@ViewScoped
public class RegistrationController { 

    @Inject
    RegistrationService rs;

    User current = new User();

    public void register() { 
        rs.register(u);
    }

    // get set for current user
}

// view
// quite a lot boilerplate omitted
// form omitted which displays all the necessary field of your current user
// via value="#{registrationContoller.current.name}"
<h:commandButton value="submit" type="submit" action="#{registrationController.register}" />

Answer 2

It does not. They are conceptual different. MVC uses a MVC model, and jsf uses a handler based model.

The face of you page is done with the XHTML file. The handler handles the use input like submitting form. A binding exists between the form elements and the handler, normally using getters and setters. So if the user submits a form an method of you handler is called and all the submitted data is already in place for use to process (thank to the load of event phases).

So your XHTML file gives you username and password. The handler method is called. You do the lookup of the credentials and return a string, forwarding the user to a new page.

As said before, you cannot map the two technologies. It's like sending an email or sending a written letter. Yes, they transport information, and yes it is a relay messeging system. But the way how it is done is totally different. It is the same clash of paradigm when writing jsf and then switching to wicket.