good point. Naming was not my focus here though, it was just a quick example.
On Tue, Sep 27, 2011 at 1:55 PM, Max Rydahl Andersen < [email protected]> wrote: > don't use save or saveOrUpdate - those are old Hibernate API methods which > doesn't do the same as what update/persist does. > > The semantics are similar but different enough to not overload the words > since it requires a different usage of the API. > > My 2 cents ;) > > /max > > On Sep 27, 2011, at 17:57, Jason Porter wrote: > > > I prefer the idea that there's a class that manages one instance and > that's all it does, and another object (or objects) to handle collections of > those objects. I think separating them out makes for better reusability. If > we'd like to have a save method I'm okay with that, but don't really see the > need. > > > > Sent from my iPhone > > > > On Sep 27, 2011, at 7:32, José Rodolfo Freitas < > [email protected]> wrote: > > > >> Sorry for not being able to post my gist. After writting some > "sketches", I realized that I don't have it very clear in my mind yet. > >> > >> just to move from zero I posted something: > >> > >> https://gist.github.com/1245041 > >> > >> It's a really simple example on how we could avoid inheritance, but > it's not contemplating a lot of needed features, > >> so I'm not even near to be convinced with that gist. > >> > >> btw, the @AutoHome approach seems very nice. > >> > >> > >> On Thu, Sep 22, 2011 at 2:12 PM, Dan Allen <[email protected]> > wrote: > >> Exactly. flush() has a specific purpose and really doesn't belong in > boilerplate code. > >> > >> - Dan Allen > >> > >> Sent from my Android-powered phone: > >> An open platform for carriers, consumers and developers > >> > >> On Sep 22, 2011 11:19 AM, "Max Rydahl Andersen" < > [email protected]> wrote: > >> > just one comment: > >> > > >> > Calling .flush() on every alteration really should not be promoted as > a good practice. > >> > > >> > /max > >> > > >> > On Sep 22, 2011, at 24:22, Dan Allen wrote: > >> > > >> >> 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. > >> >> > >> >> @Name("jobServiceBean") > >> >> @Scope(ScopeType.CONVERSATION) > >> >> public class JobServiceBean implements JobService { > >> >> private EntityManager entityManager; > >> >> private StatusMessages statusMessages; > >> >> > >> >> @In > >> >> public void setEntityManager(EntityManager entityManager) { > >> >> this.entityManager = entityManager; > >> >> } > >> >> > >> >> @In > >> >> public void setStatusMessages(StatusMessages statusMessages) { > >> >> this.statusMessages = statusMessages; > >> >> } > >> >> > >> >> public boolean update(Job job) { > >> >> this.entityManager.flush(); > >> >> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully > updated job {0}", job.getName()); > >> >> return true; > >> >> } > >> >> > >> >> public boolean close(Job job) { > >> >> job.setJobStatus(JobStatus.CLOSED); > >> >> this.entityManager.flush(); > >> >> this.statusMessages.add(StatusMessage.Severity.INFO, "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 > >> >> > >> >> http://www.google.com/profiles/dan.j.allen#about > >> >> http://mojavelinux.com > >> >> http://mojavelinux.com/seaminaction > >> >> > >> >> _______________________________________________ > >> >> forge-dev mailing list > >> >> [email protected] > >> >> https://lists.jboss.org/mailman/listinfo/forge-dev > >> > > >> > /max > >> > http://about.me/maxandersen > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > forge-dev mailing list > >> > [email protected] > >> > https://lists.jboss.org/mailman/listinfo/forge-dev > >> > >> _______________________________________________ > >> seam-dev mailing list > >> [email protected] > >> https://lists.jboss.org/mailman/listinfo/seam-dev > >> > >> > >> _______________________________________________ > >> seam-dev mailing list > >> [email protected] > >> https://lists.jboss.org/mailman/listinfo/seam-dev > > _______________________________________________ > > forge-dev mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/forge-dev > > /max > http://about.me/maxandersen > > > >
_______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
