JSF is almost pure MVC.
I sat
almost, because pure MVC isn't possible for any web-based framework, since part of MVC is that if the model changes, the controller should post updates to the view, and HTTP isn't allowed to send unsolicited data. The next best thing is to send the view updates as part of a response to a subsequent request, and that's what JSF will do.
Unlike most desktop GUIs, JSF doesn't typically involve much controller coding, only Models and Views. For the most part, the controller is in the JSF tag implementations and in the JSF framework itself.
Backing Bean properties can be set either by having an action that references the bean do the setting (via invocation of the bean's mutator methods) or by the constructor process for Managed Beans. Unlike Struts Form Beans, JSF backing beans were intented to be pure POJOs. In real life, they often contain JSF model objects, so they're not strictly generic, but they're close. One common failing for newbies is stuffing JSF backing beans with a lot of javax.faces method and object references. That's actually not a very good practice. In many cases, it means they're not taking advantage of JSF's simplified mechanisms for achieving their goals. In many other cases, it's possible to excerpt the non-portable code to another place. Doing that makes it easier to reuse the bean in a non-JSF environment and to do
unit testing on the bean outside the
J2EE container framework.