Ah, our esteemed Mr. Tsang has learned his lessons well!
It's true, JSF is a relatively pure implementation of the Model/View/Controller paradigm. The Models are backing beans (POJOs), the Views are defined in templates, and the Controllers are pre-supplied - you don't write Controllers in JSF.
One thing that confuses a lot of people (besides thinking that the Action Methods in backing beans are Controller methods, and they aren't), is that in a complex webapp, you actually have 2 types of Model object.
The JSF backing bean is a UI (MVC) Model.
The persistence objects (Entity EJBs) are Data Object Model objects.
Both JSF backing beans and ORM persistence Model objects are POJOs, which means that in certain very rare cases, you
can have a dual-use object which serves as both a persistable object and as a Managed Bean.
But those are VERY rare cases, since JSF cannot lookup persistent objects by key, only instantiate via no-argument constructors.
You can make an entity object be a contained property of a backing bean, since the backing bean's support logic can have CRUD methods in it, thus making it possible to do a "find" for an existing object. So the Entity object "Person" won't work as a backing bean, but an "EmployeeToEdit" backing bean might have a "person" property that would be a fetched
EJB corresponding to the person to edit.
I usually don't use EJBs as such these days - I use Hibernate JPA. My "standard" JSF web application uses JSF to instantiate and wire the Managed Beans and Spring Framework to instantiate and wire support beans such as the persistent Service objects and DAOs. So usually something like this:
The Business logic MAY fold into the Backing bean if it's simple enough, and not worthy of re-use. The Persistent Services manage "working sets" of persistent objects. Meaning, for example, a parent and set(s) of children treated as a transactional
unit. The DAO Services do the table-level finder and CRUD operations for the Persistent Services, and since the Persistent Services are transactional, the necessary DAOs all operate within a single persistent service transaction. Found Object Models are presented as working sets and passed back up to the Business or Backing Bean layers, since, as I said, they cannot be actual backing beans, but they can serve as property objects of backing beans. I don't leave the EntityManager connected at that level, however. Once you've exited a Persistent Service, the objects are detached. Not everyone does this, but I consider it more resource-efficient and less likely to result in inexplicable random object changes.
Obviously this scheme does work with EJBs, too. Just make the Persistent Services and DAOs be Session Beans.
