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