Yep then I misunderstood. I thought you were saying the object *should* know about persisting themselves, which I don't think is a good idea personally, though again, it really is personal preference. There are pros and cons to either approach. :-)
On Feb 1, 2008 6:19 PM, Jaime Metcher <[EMAIL PROTECTED]> wrote: > @Brian: > I agree completely. I'm sure I haven't expressed myself very well, but > maybe for fun go back through my points and your points and see if you can > make them map - to me, they map exactly. This phrase - "persistence is an > intrinsic property of an object" - maybe is a problem. You put it like > this - "in objectland, objects exist forever" - which is exactly what I was > trying to say. With the implication that for a domain object, a save() > method doesn't make sense - right? > > I would also say things like "memory allocation is an intrinsic property > of an object" - meaning that the object has a memory allocation simply by > virtue of existing - *not* that every object should have a malloc() method!! > > @Baz > You're scaring me, people don't usually agree with me on these forums! > Just so we're clear - we talking concepts, here, right? Actual > implementation will always have one eye on how far the existing frameworks > will get us, and the other eye on our ROI. Trying to stay "pure" can get > real hard (read "expensive") real quick. > > Jaime > > -----Original Message----- > *From:* [email protected] [mailto:[EMAIL PROTECTED] Behalf > Of *Brian Kotek > *Sent:* Saturday, 2 February 2008 1:34 AM > *To:* [email protected] > *Subject:* [CFCDEV] Re: myBean.save() versus myServiceObj.save(myBean) > > > > On Jan 31, 2008 6: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). > > > > Ben Nadel has a very timely post about how my friend Hal exposed him to > the idea of idealized objects. I disagree that peristence is an "intrinsic > property" of an object. And just becuase in real life your scribble analogy > holds, it does not need to hold true in the OO world! If you don't want > scribbles in your book and they aren't important to you, your book object > can totally ignore them. In fact, it wouldn't even LET you scribble in the > margin! There would be no book.scribble() method. > > > > > > 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. > > > > > > But this also doesn't carry over to Obejctland. In Objectland, objects > exist forver, or until they are explicitly destroyed. In an ideal world our > servers would have infinite RAM, a nuclear power supply, and unlimited > processing power. We'd never have to persist anything to a database. > Unfortunately, the real world won't cooperate with us here, so we do need > databases. But I don't think that is something our domain objects should > know about. Let them remain in their blissful ignorance, and some poor > supporting code (which is what the Service layer is, after all) be forced to > know of the plight of our poor objects. Since the domain objects are really > the core of an OO system, I'd rather leave them as ignorant as possible > about the confines of their existence and leave them free to model the world > in most ideal way we can come up with! > > > > 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? > > > > > > Exactly. In fact, why would you create it if you didn't want it to stay > around *forever*, or at least until it is explicitly destroyed? If you buy a > model ship and put it together, you don't take it back apart and put it in a > box when you're not using it, only to pull it out and put it all back > together again the next time you want to look at it. It's put together and > stays that way until you decide to throw off the roof. > > > > 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. > > > > > > While I think the question of whether a scratchpad or "temporary object" > (not sure what that means) are "domain objects" is open to debate (if your > app needs a scratchpad, there could easily be a Scratchpad object). But here > you seem to be unconsciously reversing your prior points. You're right, the > object should exist forever until someone destroys it. Note "destroys it", > not "saves it to a database". > > So I've tossed my 2 cents in! :-) > > Brian > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
