> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sean > Corfield > > This is simply just not idiomatic CF (nor idiomatic in many other > languages either). Implementing a workaround is really just adding an > (unnecessary) layer of abstraction for no real benefit - it's an > artificial layer.
So idiomatic is: Use a gateway object for returning recordsets of persisted data Use a DAO object for returning a single record of persisted data as a dumb bean Use a "Manager" object for dealing with multiple objects of the same class Use a "Service" object for dealing with multiple objects of multiple classes Maybe use a factory object to help with complex instantiation, maybe composed into the service or manager Create "fat" model objects and give them references to all of the above where needed. Something like that? So "class" methods could go into any of the last four, depending on the emphasis. Would you recommend I check out the FB5 core for examples of this stuff? I haven't looked at it but I'd guess it's light on the persistence side of things. > > > 2. Query recordsets aren't objects. > > You already have the gateway object that you could hide the mapping > inside so you do not need to resort to views in the database. But, > again, I think this is a case where you're trying to artificially wrap > a change in requirements that is always going to have some impact > somewhere. I'd have to do it twice, once in the gateway and once in the DAO, right? Not DRY. > > > drops me out of object-think and into thinking about how the > plumbing works, > > Because you're crossing the boundaries between logical and physical > design too often. You're trying to think ahead and implement your > design piecemeal. In other words, it isn't ColdFusion causing this > cognitive dissonance - it's your own approach. > I'd love to know how to avoid this. I'm constantly going between "what am I trying to do here" (logical) to "how do I implement that" (physical) and the reverse, "has this implementation (physical) correctly reflected my intent (logical)". There are a set of mappings between the logical and physical that I've perhaps unfairly called workarounds. Maybe once these are truly assimilated it all becomes easier. But for me its very difficult to learn anything I don't understand, and I do find some of the CF idioms baffling. Applying the principles of encapsulation, coherency and DRY I come up with very different answers. Another question: do you assert that it's worth giving up something in terms of encapsulation, coherency and DRY in order to remain idiomatic; or that there's no conflict and you can promote all of these? > > Does that help? Time will tell! Always thought provoking, Sean, and very much appreciated. Jaime Metcher You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
