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