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
_______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
