Sorry for not being able to post my gist. After writting some &quot;sketches&quot;, I realized that I don&#39;t have it very clear in my mind yet.<div><br></div><div>just to move from zero I posted something:</div><div><br>
</div><div><a href="https://gist.github.com/1245041">https://gist.github.com/1245041</a></div><div><br></div><div>It&#39;s a really simple example on how we could avoid inheritance,  but it&#39;s not contemplating a lot of needed features,</div>
<div>so I&#39;m not even near to be convinced with that gist.</div><div><br></div><div>btw, the @AutoHome approach seems very nice.</div><div><br><br><div class="gmail_quote">On Thu, Sep 22, 2011 at 2:12 PM, Dan Allen <span dir="ltr">&lt;<a href="mailto:dan.j.allen@gmail.com">dan.j.allen@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><p>Exactly. flush() has a specific purpose and really doesn&#39;t belong in boilerplate code.</p>
<p>- Dan Allen</p>
<p>Sent from my Android-powered phone:<br>
An open platform for carriers, consumers and developers</p><div><div></div><div class="h5">
<div class="gmail_quote">On Sep 22, 2011 11:19 AM, &quot;Max Rydahl Andersen&quot; &lt;<a href="mailto:max.andersen@redhat.com" target="_blank">max.andersen@redhat.com</a>&gt; wrote:<br type="attribution">&gt; just one comment:<br>
&gt; <br>
&gt; Calling .flush() on every alteration really should not be promoted as a good practice.<br>&gt; <br>&gt; /max<br>&gt; <br>&gt; On Sep 22, 2011, at 24:22, Dan Allen wrote:<br>&gt; <br>&gt;&gt; Here&#39;s some additional feedback I received from a community member a while back...to merge it into this thread.<br>

&gt;&gt; <br>&gt;&gt; (begin feedback)<br>&gt;&gt; <br>&gt;&gt; ...from being burned from 3 seam based customers with apps and maintenance.  The &quot;Home&quot; 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 &quot;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.  <br>

&gt;&gt; <br>&gt;&gt; 1. My &quot;Home&quot; now is a &quot;ServiceBean&quot;, and I have one for each &quot;Major&quot; entity, see below.  I have really stewed over this over months and months, and the &quot;Home&quot; of &quot;ServiceBean&quot; should be kept small, focused, reusable, tested and untouched.  It&#39;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&#39;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&#39;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. !<br>

&gt;    After this is tested, and what I need I usually don&#39;t touch it anymore.  If I need to enhance I either use a decorator pattern around it, or enhance it in an @Observer.  I&#39;ll email about that later.<br>&gt;&gt; <br>

&gt;&gt; @Name(&quot;jobServiceBean&quot;)<br>&gt;&gt; @Scope(ScopeType.CONVERSATION)<br>&gt;&gt; public class JobServiceBean implements JobService {<br>&gt;&gt;     private EntityManager entityManager;<br>&gt;&gt;     private StatusMessages statusMessages;<br>

&gt;&gt; <br>&gt;&gt;     @In<br>&gt;&gt;     public void setEntityManager(EntityManager entityManager) {<br>&gt;&gt;         this.entityManager = entityManager;<br>&gt;&gt;     }<br>&gt;&gt; <br>&gt;&gt;     @In<br>&gt;&gt;     public void setStatusMessages(StatusMessages statusMessages) {<br>

&gt;&gt;         this.statusMessages = statusMessages;<br>&gt;&gt;     }<br>&gt;&gt; <br>&gt;&gt;     public boolean update(Job job) {<br>&gt;&gt;         this.entityManager.flush();<br>&gt;&gt;         this.statusMessages.add(<a href="http://StatusMessage.Severity.INFO" target="_blank">StatusMessage.Severity.INFO</a>, &quot;Successfully updated job {0}&quot;, job.getName());<br>

&gt;&gt;         return true;<br>&gt;&gt;     }<br>&gt;&gt; <br>&gt;&gt;     public boolean close(Job job) {<br>&gt;&gt;         job.setJobStatus(JobStatus.CLOSED);<br>&gt;&gt;         this.entityManager.flush();<br>&gt;&gt;         this.statusMessages.add(<a href="http://StatusMessage.Severity.INFO" target="_blank">StatusMessage.Severity.INFO</a>, &quot;Successfully closed job {0}&quot;, job.getName());<br>

&gt;&gt;         return true;<br>&gt;&gt;     }<br>&gt;&gt; }<br>&gt;&gt; <br>&gt;&gt; 2. One thing you may have noticed from above that there is no &#39;instance&#39; field with corresponding getters or setters like the old &#39;Home&#39;.   So the ServiceBean in my case is not a full crud, but CUD + your own business methods. That&#39;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 &quot;home&quot; or in my case the &quot;ServiceBean&quot;.<br>

&gt;&gt; <br>&gt;&gt; (end feedback)<br>&gt;&gt; <br>&gt;&gt; -- <br>&gt;&gt; Dan Allen<br>&gt;&gt; Principal Software Engineer, Red Hat | Author of Seam in Action<br>&gt;&gt; Registered Linux User #231597<br>&gt;&gt; <br>

&gt;&gt; <a href="http://www.google.com/profiles/dan.j.allen#about" target="_blank">http://www.google.com/profiles/dan.j.allen#about</a><br>&gt;&gt; <a href="http://mojavelinux.com" target="_blank">http://mojavelinux.com</a><br>
&gt;&gt; <a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br>
&gt;&gt; <br>&gt;&gt; _______________________________________________<br>&gt;&gt; forge-dev mailing list<br>&gt;&gt; <a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>

&gt; <br>&gt; /max<br>&gt; <a href="http://about.me/maxandersen" target="_blank">http://about.me/maxandersen</a><br>&gt; <br>&gt; <br>&gt; <br>&gt; <br>&gt; _______________________________________________<br>&gt; forge-dev mailing list<br>

&gt; <a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>&gt; <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</div>
</div></div><br>_______________________________________________<br>
seam-dev mailing list<br>
<a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br>
<br></blockquote></div><br></div>