the CallBacks Dilemma

EDIT: I think Barney's comment did actually help me (although I may not have realized it at the time), to find a better way to handle the more traditional ORM in DataFaucet and I've since published a new version of DF (1.1 RC1) with a more traditional ORM tool that uses your objects from a Dependency Injection (DI) factory. The good news imo is that the new tool doesn't require any call-backs in CacheBox. Although I think this is still a valid question: are there cases in which we actually need call-backs from the cache service? Should they be implemented in CacheBox? I'm inclined to say no, but I'd still like to know what others think.

[More]

Comments
Barney Barney Boisvert's Gravatar I think you're missing the point with cashing in an ORM framework. The Bob object should never have a reference to the Karen object (nor the converse), it should just appear as if he does. What should happen on bob.getWife() is the ORM framework should look up in the session/transaction/unit-of-work to see if it already knows about Karen. If so, use it, otherwise hit the DB. Then Karen can be expired at any time without Bob caring, even in the middle of a unit of work. Everyone keeps their own isolated workspace with loaded object (all of which can be discarded at session close), and you can reap cache simply and with impunity.
# Posted By Barney Barney Boisvert | 9/22/09 3:04 AM
ike's Gravatar Thanks Barney. Of course that would be my preference. But the reason for all this back and forth in the blog over the dilemma isn't because of the concept, but rather because of what's available to implement it in current versions of CF.

I don't have a relatively simple "wrapper" object that I can just layer over the original object that will act in all ways identical to the original object. I can come close with onMissingMethod or with inheritance, both of which potentially cause other issues.

OnMissingMethod doesn't support plain-old variables in the "this" scope and potentially causes object type exceptions depending on how the other person writes their code, and of course the objective is to make it seamless so it doesn't matter how they write their code.

Inheritance solves those two issues, but then creates some other potential issues like what if the person wanted special logic in the getWife() method? And I'm also back to using code-generation, which I generally try to avoid. I think this inheritance route may ultimately be the one I go with because it seems the least likely to cause problems.
# Posted By ike | 9/22/09 12:15 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.5.006. | Protected by Akismet | Blog with WordPress