Probably want to be careful here too, because now you have transaction management moving from the Service into the Beans. And what happens if the Service wants to control saving more than one Bean in a Transaction? It can't, because the Beans have transactions in them and unfortunately we can't nest transactions in CF. This could open up its own can of worms just as easily. :-)
On Jan 31, 2008 8:04 AM, Alan Livie <[EMAIL PROTECTED]> wrote: > > I've been discussing this with a colleague. > > He mentioned one benefit of myBean.save() is that if your bean is composed > of other beans (and they are all composed with their own DAO's) then the > service layer doesn't need to know too much about the composition of the > beans. > > myBean.save() therefore runs save() on its own DAO as well as save() on > its composed beans. > > If it's the service layer doing the myDAO.save(myBean) then it would also > have to run save() on other DAO's ...either that or the DAO would have to > then call save() on other DAO's etc. I can see this getting messy. > > I think I can see the pros and cons of both options now. > > Alan > ________________________________________ > From: [email protected] [EMAIL PROTECTED] On Behalf Of Peter > Bell [EMAIL PROTECTED] > Sent: 31 January 2008 12:54 > To: [email protected] > Subject: [CFCDEV] Re: myBean.save() versus myServiceObj.save(myBean) > > It isn't the DAO that'd be a transient - it'd be the User business object > that (if ColdSpring served it up) would be a transient (singleton=false). > You'd inject the singleton DAO into it. > > Proviso: Some people on the lists have recommended NOT using ColdSpring > for > transients, but creating a custom factory instead (or I use LightWire). > Others have used ColdSpring for instantiating their transients without > problems. > > Best Wishes, > Peter > > > On 1/31/08 5:30 AM, "Michael Sharman" <[EMAIL PROTECTED]> wrote: > > > > > Hi Peter, > > > >> - For user.save() you need to inject a DAO into your transients which > >> requires ColdSpring with singleton=false > > > > Would the DAO composed into the User bean not be a singleton? Why > > would you need a 'per instance' DAO for each and every User bean? > > > > On Jan 31, 4:16 am, Peter Bell <[EMAIL PROTECTED]> wrote: > >> Hi Alan, > >> > >> Been pretty much beaten to death on cfcdev over the years. Short > answer, it > >> isn't right or wrong - more a matter of preference. > >> > >> I prefer syntactically User.save() to UserService.save(User), but > that's a > >> pure preference Others prefer it the other way round. > >> > >> Provisos: > >> - Don't put SQL in the bean - eithr way the saving should be delegated > to a > >> DAO > >> - For user.save() you need to inject a DAO into your transients which > >> requires ColdSpring with singleton=false, a custom factory or > lightwire. > >> - If you need to support remote method cals, you're going to need a > >> Userservice.save() method. I have one for remote calls ad it just > delgates > >> to a new bean it creates. Some may prefer just to have the service do > the > >> save all the time, but again it's down to preferences. > >> > >> Best Wishes, > >> Peter > >> > >> On 1/30/08 12:03 PM, "Alan Livie" <[EMAIL PROTECTED]> wrote: > >> > >> > >> > >> > >> > >>> We currently use the service object to save a bean (which uses a > >>> gateway/DAO its composed with to do the work) > >> > >>> Another developer has suggested the bean should save really be > >>> responsible for saving itself (again using a DAO its composed with). > >> > >>> This looks like a good one for a discussion! :-) > >> > >>> Alan- Hide quoted text - > >> > >> - Show quoted text - > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
