When To Use Home vs @PersistenceContext?

[gzoller.greg.zoller.aviall.com]

Hello,

I'm trying to understand persistence within Seam.  I've used seam-gen to create a simple app against an existing database and noticed that it generated a set of xxxHome objects for my entities that extend EntityHome to handle persistence operations.  I also see examples elsewhere that use @PersistenceContext to inject an EntityManager (i.e. into an action class) to do persistence operations.

Is this really just two equal-but-different ways of doing the same thing?  If so, is one more recommended in some circumstances?  Just trying to understand how/why I'd choose one approach over the other before I get too far writing a lot of code.

Thanks!
Greg

[admin.admin.email.tld]

Very good question.  I believe the seam generate commands create classes that extend the EntityHome class and associated classes in the org.jboss.seam.framework package.

SAF is defined as A framework for data access in Seam.
http://docs.jboss.org/seam/2.0.0.GA/api/org/jboss/seam/framework/package-summary.html.  Provides support for CRUD and queries.

AFAIK, the dvdstore example is the only example in the 2.0.1 distro that uses the EntityHome class.  Which makes it confusing as to what we should use in terms of best practices (something which is basically still lacking in the JBoss Seam community - although the knowledgebase on this forum and books do help).

It's part of the Seam Application Framework (see Ch.11 of the Seam ref pdf).  There's also good coverage of SAF in the upcoming Seam in Action book.

There's some advantages to using it, like
Pete Muir's knowledgebase post.

We decided to go with a DAO layer that extends JPA and Hibernate base classes (similar to the CaveatEmptor model).

The problem I've run into is when a dataTable is based on data from more than one entity.  The you must either create a composite DAO or just write a JPA/Hibernate query that will return the result set.

As far as the injection of EntityManager is concerned, it's recommended to use @In/SMPC instead for a long-running conversation.

[gzoller.greg.zoller.aviall.com]

Thanks, Arbi.  This is a helpful answer that has given me something to think about, as does Peter Muir's posting.

I'll have to ponder what direction we need to take but it sounds like one way to slice it is to use @In/SMPC or EntityManager injection for conversation-scoped persistence and Home objects for longer-running needs.  I tend to like the EM injection for its simplicity over having extra classes but I can see the other way too.

[admin.admin.email.tld]

One of the advantages of using the Seam framework for your JavaEE projects is that there is little to no layering.  In other words, there is no Action class, business delegate, proxy, DTO, DAO, session facade (unless you want there to be).  Click a button on JSF, execute method on SFSB.  no b.s.  no xml hell.

Separation of concerns is a big thing so some people like to abstract out their data access layer and this will facilitate unit testing, code management and reusability.  If you are designing and implementing a large project that has a db with many tables that may be accessed by multiple apps, then you may want to implement a DAO layer/library that can be re-used by multiple apps.

If it's a small app that is mostly CRUD and little business logic (e.g. no workflow required, no intensive calculations, no web services integration, etc.) then you can get away with using EntityManager directly in your SFSB/SLSB/POJO classes without too much worry.  And if need be, refactor out to abstract the DAO layer later.

This is the gist of what GKing was talking about in this
insightful interview.

We don't have anybody using the SAF with EntityHome, etc. here at Cox AFAIK but that may be a bad thing...  I'm pretty sure there was a reason for that, however, and it may have to do with the fact that when you run seam generate-entities (or is it model now?), you would also get xhtml files created whose page flow was not necessarily what you wanted for your particular use cases...