Baz, It's just a different slant. The idea is that persistence isn't something you do, it's an intrinsic property (or not) of an object. It's like if I get a book out of the library, scribble in the margins, then take the book back, my scribbles aren't going to suddenly disappear. If I want to make unpersisted changes, I'll have to photocopy the book and scribble on the copy. Persistence may not be a property of my photocopy (i.e. I'm in the habit of just binning them when I'm done).
Why is this a good idea? Three thoughts: 1. At a higher level, what's the number one problem ordinary users have? Created a document, didn't save it, computer crashed. The very notion that you would create something that you *didn't* want to save is bizarre to these users. The fact that you have to remember to explicitly save is the only proof most people need that computer programmers hate humankind. 2. This whole persistence thing greatly distorts thinking about domain models. Ideally I'd like to just code up the domain model TDD-style, so I'm instantiating objects, testing them, tearing them down again. Later, once I'm done, I'm interested in having these domain objects hang around between runs, so I slide in a persistence layer underneath, with zero changes to my domain model. How do I know which objects to save? Well, all of them, of course. At the domain model layer, why would I create a Widget if I didn't want it to stay around? 3. In the UI layer, sure, I might want temporary objects, scratchpads, in-progress objects, etc. None of those things are domain objects. With a domain object, once I create it, I want it to stay around until I explicitly delete it. In general, I really only want to care about two lifespans for objects - function local, and forever until someone else destroys it. Everything else is performance optimization. Obviously in the real world *lots* of performance optimization is necessary. It just try to keep in view the pure concepts as a reference. Jaime -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] Behalf Of Baz Sent: Friday, 1 February 2008 9:03 AM To: [email protected] Subject: [CFCDEV] Re: myBean.save() versus myServiceObj.save(myBean) @Mark, Jaimie Auto-persistence seems interesting, but how often do people want to save on every request? It seems like there are many situations when you don't actually want to save even though you modified the data. Also what messiness is being avoided, calling the save() method? Baz On Jan 31, 2008 12:27 PM, Michael Sharman <[EMAIL PROTECTED]> wrote: @Peter > 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. Just as I thought, thanks for clearing that up! On Jan 31, 11:54 pm, Peter Bell <[EMAIL PROTECTED]> wrote: > 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 -- 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 -~----------~----~----~----~------~----~------~--~---
