This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
For those not familiar with the Seam Application Framework within Seam (yeah, probably a bad name) it provides a lot of the functionality we end up using for CRUD and searching the data model. That puts it very lightly, Dan expounds on this at length in Chapter 11 of his book.
My question to everyone out there familiar with Seam (not just Dan) is when to use it and when to simply inject the EntityManager (or Hibernate Session)? Sure the Query, Home, and Controller classes will take you a long way (and it's a great place to see how Seam works), but is there some point where they simply don't provide enough capability?
I'd love to hear what other folks have to say, though I am sure there are those that are eager to know what I think. First and foremost, check out chapter 10 (to correct Jason) of Seam in Action to learn the ins and outs of this subframework in Seam.
The Seam Application Framework is a great way to start with Seam. It saves you a lot of time and if the use case fits, you can even get away without writing any Java code at all. You merely configure it in XML. From there, you can extend the framework classes to get more functionality out of them, perhaps even to create your own abstract classes. I have done this with much success. Before you abandon the framework and start from scratch developing your own components, in which you would inject an entity manager, think about injecting a Seam Application Framework class, in a sense taking a hybrid approach.
With all of that said, if you are ready to go at it on your own, rather than try to extend what Seam has to give you, be a villain and steal the code! It's open source after all and that is the beauty of it. I have a client right now who used the Seam Application Framework as an open book and implemented a similar hierarchy of classes, but tuned it to his needs.
One point I want to make about Home. The Home class is unique in that it goes another step in preventing the LazyInitializationException because it fetches the record before JSF applies updates to it, so even if you are outside of a long-running conversation, you don't have to merge to have those changes detected. Recall that once you load the record from the persistence context, it starts monitoring the object for changes. Because of the ordering that Home uses, you get that for free (i.e., without thinking about it). What you lose by not using a long-running conversation is the optimistic locking guarantee.
As a final note, I love using the Query framework to back lookups for a select menu (i.e., lookup tables). I don't have to write code and I can centralize my queries in components.xml.