[forge-dev] [seam-dev] SAF (aka Entity Framework) idea in Seam 3

Dan Allen dan.j.allen at gmail.com
Wed Sep 21 18:22:33 EDT 2011

Here's some additional feedback I received from a community member a while
back...to merge it into this thread.

(begin feedback)

...from being burned from 3 seam based customers with apps and maintenance.
The "Home" or any other name should be just be put into a grave and slowly
cast away to sea ;).  It is too heavy and complicated and just about
anything inherited (extends) truly causes heartache[Favor Composition over
inheritance: Effective Java]. The current seam home has a few super classes
above the home and when you try to unit test it (the standard definition of
unit-testing including isolation) you get the "No Active Application Context
Found (if I remember it right).  That happens because it is tightly coupled
with the application.  But not to be hard on Home, I do realize the history
of the home object and know it was developed when EL had no parameters. So I
have learned a lot since then and I here are some things that I can impart
to Seam 3.

1. My "Home" now is a "ServiceBean", and I have one for each "Major" entity,
see below.  I have really stewed over this over months and months, and the
"Home" of "ServiceBean" should be kept small, focused, reusable, tested and
untouched.  It's only task is to update, persist, possibly remove, or some
other functions that are required.  In my example below I have custom close
action.  Notice also that although these beans are stateful that doesn't
mean everything should be, so in these methods I have the parameter of what
is being needed to be updated, and not a field.  In other words I don't have
@In private Job job, I opted for public boolean update(job).  Mostly
because, again, I want to make this service bean reusable so whether I have
a #{newJob}, #{copyOfAJob}, or #{managedJob} or whatever component of job I
need to work on I only need one jobServiceBean to cater to all my jobs, in
whatever conversation I am using.  I also fire events from here if I need to
do that.   After this is tested, and what I need I usually don't touch it
anymore.  If I need to enhance I either use a decorator pattern around it,
or enhance it in an @Observer.  I'll email about that later.

public class JobServiceBean implements JobService {
    private EntityManager entityManager;
    private StatusMessages statusMessages;

    public void setEntityManager(EntityManager entityManager) {
        this.entityManager = entityManager;

    public void setStatusMessages(StatusMessages statusMessages) {
        this.statusMessages = statusMessages;

    public boolean update(Job job) {
"Successfully updated job {0}", job.getName());
        return true;

    public boolean close(Job job) {
"Successfully closed job {0}", job.getName());
        return true;

2. One thing you may have noticed from above that there is no 'instance'
field with corresponding getters or setters like the old 'Home'.   So the
ServiceBean in my case is not a full crud, but CUD + your own business
methods. That's because that too should be decoupled because we never know
the source of the object is.  Is the object created from a factory? from a
copy? is it a mapped component, a managed component?  Creation of objects or
loading of objects, or the manufacturing of objects from factories should be
separate from the "home" or in my case the "ServiceBean".

(end feedback)

Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20110921/dfa9b718/attachment.html 

More information about the forge-dev mailing list