Yes it is personal preference. I actually prefer that the bean know
absolutely nothing about how it might be persisted, which means I like to
save it in the Service. To me, a domain object should think that it exists
forever in memory. So if the Service saves it and it dies, only to be
resurrected later by the Service, the bean never even knows anything
happened. As far as it is concerned, it was always in memory. The fact that
something else put it in "suspended animation" (in the database) is
something it is never aware of. But again, just my preference.

On Jan 30, 2008 12:16 PM, 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
> > >
>
>
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to