Great post, I'm sold. I'm going to keep that in the foreground while I code for the next little while to see how t feels.
Baz On Jan 31, 2008 3:57 PM, Jaime Metcher <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
