There are also other approaches, like "Active Record," but in my opinion, the EntityManager poses a bit of a problem: It requires that it must already know about the entity. And in my experience that is an inherently difficult problem to overcome when attempting to build truly stateless applications - resulting in duplicate calls to the database to fetch data that you already have (just to sync things up.) While this is good for things like transactionality, it is bad for performance, but before I get too far off topic here, I'm just going to stop :) In a sense, we are fighting against JPA combined with a Strongly Typed language. I think that the lambico approach (annotating interfaces, like what Spring did - yep I said it) is actually the best approach I've seen in a long time.
The other point to make here is that the reason we need a class at all is because the EntityManager only gives us part of what we need. It certainly does CRUD. But it does provide transaction boundaries, it does not hold a reference to the active instance and some of it's methods require knowing the context (persist vs merge vs the implicit update). We don't necessarily want to hide the EntityManager, since a philosophy of Seam has always been to keep the native APIs exposed and unwrapped. But we do want to keep the developer's codebase dry.
...with that said, I'm fine with a "smarter" entity manager class that can be used as a delegate. But I do think there is merit in offering a class to extend for rapid development scenarios.
Jose, could you make a gist for how you would create a bean for managing an entity instance using the composite pattern? I'm asking so we have something to contrast.
(btw, the term EntityHandler sounds reasonable to me. Another approach Jason and I had was EntityInstanceManager, or *Handler. We want to distinguish between the EntityManager which manages all instances and a component that manages just a single instance).
-Dan