Hi all.. I know that I never involved on this mailing-list so much, nor contribute things to the community. But because I have an experience with seam 2 and used seam gen extensively (and thus use seam's EntityQuery and EntityHome a lot) in some project, I have a thought about this.
EntityQuery anda EntityHome is perfect in case you want to creating an simple CRUD application. Well, not as simple as is. I ever involved in a project with 40 more database tables with quite extensive financial transaction, and use an EntityQuery and EntityHome a lot. The main problem with these classes is that, It's hard (well, at least, for me) to
make your code consistent. What I mean by consistent is that, it is confusing to determine whether the classes is a part of your UI layer, or service/domain-model layer. Or where you add new functionality to satisfied a specifics requirement. The study case is maybe like this:
Let say that we have a module named accounting transaction. And we want to create a input transaction page, thus we have a TransactionHome.xhtml backed with TransactionHome.java. Now the problems occurs. Because we want a chart of account list in the TransactionHome.xhtml, where is better place to put the logic to call the chart of account list? In the TransactionHome.java, or
ChartOfAccountList.java?
In the beginning I put it in the ChartOfAccountList.java, and start to realize that seam's EntityList is specialized class to create a page with contains a rich datatable search option, paging, and sorting. It will be strange to the code if try to add non searching/sorting/paging on it. Then I think to back to good-old DAO object, and thinking again about the backing bean: I need to call/inject the DAO in some backing-bean, but where? TransactionHome.java? Well, TransactionHome already have getEntityManager(), so if I put the DAO in the ***Home, it will looks overlapping, and bit odd. Then when I thinking again about the EntityHome, I'm not sure whether I need to treat this class as UI or Service class. You see, this is simple case study (don't get me start with "The list of Chart Of Account need to aligning with the logged in user's departments and user's role. And make sure that an user with level A have a $xxx limit transaction, where level B have $xxx limit").
My purpose is not to blame something or rant to something, but instead, give an idea whether is it good enough to leave ***Home and ***Query concept, and back to at least
Entity-Service-BackingBean-View model? It looks "verbose", I know, but at least we have a "service" layer, which is "centralized" place to write a business logic in our application. We could treat the "service" as just-plain-stateless classes (EJB 3.1 classes or only seam-persistence classes with minimal
coupled with the front-end layer), and put the richness of Weld and Seam 3 maybe in the UI and view layer.
Well, I know this is personal view, from me, and my experience. Thus, just ignore if in case this is annoying and not fit with your purpose/target.
Thanks,
xsalefter
The Home idea
https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/ConferenceInstance.java
The Query idea
The main thing that I would change with the Query class above is to use named queries, thus espousing the generally accepted best practice in default applications. I understand this doesn't fill all the gaps of the older SAF from Seam 2, but I think it works for the majority of cases, and it also helps people understand the best way to do things instead of relying on the magic of SAF from Seam 2 (which I have found to be a major problem in projects and teams I have worked with over the last three years).
Discuss.