<p>Exactly. flush() has a specific purpose and really doesn'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 class="gmail_quote">On Sep 22, 2011 11:19 AM, "Max Rydahl Andersen" <<a href="mailto:max.andersen@redhat.com">max.andersen@redhat.com</a>> wrote:<br type="attribution">> just one comment:<br>> <br>
> Calling .flush() on every alteration really should not be promoted as a good practice.<br>> <br>> /max<br>> <br>> On Sep 22, 2011, at 24:22, Dan Allen wrote:<br>> <br>>> Here's some additional feedback I received from a community member a while back...to merge it into this thread.<br>
>> <br>>> (begin feedback)<br>>> <br>>> ...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. <br>
>> <br>>> 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. !<br>
> 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.<br>>> <br>
>> @Name("jobServiceBean")<br>>> @Scope(ScopeType.CONVERSATION)<br>>> public class JobServiceBean implements JobService {<br>>> private EntityManager entityManager;<br>>> private StatusMessages statusMessages;<br>
>> <br>>> @In<br>>> public void setEntityManager(EntityManager entityManager) {<br>>> this.entityManager = entityManager;<br>>> }<br>>> <br>>> @In<br>>> public void setStatusMessages(StatusMessages statusMessages) {<br>
>> this.statusMessages = statusMessages;<br>>> }<br>>> <br>>> public boolean update(Job job) {<br>>> this.entityManager.flush();<br>>> this.statusMessages.add(<a href="http://StatusMessage.Severity.INFO">StatusMessage.Severity.INFO</a>, "Successfully updated job {0}", job.getName());<br>
>> return true;<br>>> }<br>>> <br>>> public boolean close(Job job) {<br>>> job.setJobStatus(JobStatus.CLOSED);<br>>> this.entityManager.flush();<br>>> this.statusMessages.add(<a href="http://StatusMessage.Severity.INFO">StatusMessage.Severity.INFO</a>, "Successfully closed job {0}", job.getName());<br>
>> return true;<br>>> }<br>>> }<br>>> <br>>> 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".<br>
>> <br>>> (end feedback)<br>>> <br>>> -- <br>>> Dan Allen<br>>> Principal Software Engineer, Red Hat | Author of Seam in Action<br>>> Registered Linux User #231597<br>>> <br>
>> <a href="http://www.google.com/profiles/dan.j.allen#about">http://www.google.com/profiles/dan.j.allen#about</a><br>>> <a href="http://mojavelinux.com">http://mojavelinux.com</a><br>>> <a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br>
>> <br>>> _______________________________________________<br>>> forge-dev mailing list<br>>> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>>> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
> <br>> /max<br>> <a href="http://about.me/maxandersen">http://about.me/maxandersen</a><br>> <br>> <br>> <br>> <br>> _______________________________________________<br>> forge-dev mailing list<br>
> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br></div>