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
>ideahttps://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/ConferenceInstance.java
>
>
>
>The Query idea
>https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/TodaysConferencesQuery.java
>
>
>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).
>
>
>I've spoken with Lincoln about this and there are two JIRAs
>(https://issues.jboss.org/browse/SEAMFORGE-280 and https://issues.jboss.org/browse/SEAMFORGE-279)
> to have Forge generate this via the JPA plugin or perhaps Seam Persistence
>plugin.
>
>
>Discuss.
_______________________________________________
seam-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/seam-dev
