Role of backing beans in MVC design

Question

Hello,
yet another JSF/MVC question. In short, I would like to know what the role of the backing beans are in an MVC design with JSF. The most simple answer would be that they are just the Controllers. But that doesn't seem enough.
Suppose I have an application model, call it Ma, which is just an interface that represents a use case in Java. Ma doesn't know anything about a view or controller, it is just domain logic with application-specific state and behavior added. Now,
- my backing bean uses Ma as its Model, acting as a true Controller by delegating requests to it
- my backing bean also adds view-specific state (show/hide stuff and it also returns a List<SelectItem> for example) that I can't put on Ma, so it also acts as a view model Mv
So, I could argue that I have an Mv-V-C design, where the backing bean is both C and Mv. My user interface V only queries Mv for its state.
Usually I read that V and C are considered to be very tightly coupled, so then I would have an Ma-V-C design with the backing bean being C and part of V.
Is it just a question of terminology or point of view, expressing the same idea twice?

Answer 1

The way I think about it is that there are multiple layers of MVC.This kind of refers to my point-of-view question. So let's try two of them.
The view itself can be thought of as containing MVC elements.When only looking at JSF (presentation layer) we have:
- Model: backing beans (view model Mv)
- View: view root and JSPs (query backing beans for state)
- Controller: Faces servlet (dispatches requests to backing beans)
In my "enterprise" quality applications, I will have three distinct layers.Taking a step back, let's look at the application layer (your "control layer", application logic behind interface) and the presentation layer.
Then:
- Model: application model Ma in application layer
- View: backing bean (associated with UI components)
- Controller: backing bean (dispatches requests to Ma)
Agree?
It's interesting that you call my application layer "control layer" since it seems more like a model to me, especiallly when you say:
The control layer consists of business logic interfaces and their implementations.This said, the objects in this application layer do have some controller functionality as they orchestrate the interactions with the underlying domain model, just llike the backing beans do with the application model. So maybe you can take another step back and consider these application logic interfaces as the View and Controller for the underlying domain model. That is: in a layered MVC design every M can become the VC for an underlying (more general) layer?
And I have seen this taken to extremes.Perhaps that's what I'm doing here :)