On 7/7/07, Jaime Metcher <[EMAIL PROTECTED]> wrote:
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.
Well, I'm not so sure that's all "idiomatic CF" but much of it is bandied around as good OO... I'd question the "dumb bean" from the DAO - it's easy enough to have "fat" business objects populated from DAOs (e.g., Transfer ORM's Decorator approach). I think "manager" objects are overused - and a symptom of "dumb beans". ObjectThink advocates eliminating managers (as much as possible).
Would you recommend I check out the FB5 core for examples of this stuff?
No, framework core code has a different set of tensions on it to application code so it tends to approach things differently. Having said that, the FB5 core is "fairly" OO in that it is entirely CFCs but the persistence is all file-based. The objects inside the FB5 are certainly complex objects - no dumb beans - but there are also some constructs which exist purely to manage boundaries between per-request and singleton operations (execution context objects). Some of these techniques also appear in Model-Glue and Mach II (since they have to solve some of the same problems).
I'd have to do it twice, once in the gateway and once in the DAO, right? Not DRY.
Have the DAO use the gateway object to retrieve a single row from the DB - which maps the column names - and then construct the bean from that row. Now you only have the mapping in one place (and no SQL in your DAO). Seems DRY to me.
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
I try to ignore the physical model for my first couple of iterations over the logical model. That stops me getting distracted. Once I'm convinced that my logical model reflects my use case scenarios and is reasonably self-consistent and rich, I start mapping logical -> physical. Now, that part I will grant is hard because it's typically not a 1:1 mapping, especially as you start introducing persistence models (since those in turn tend not to be 1:1 to your physical object model!). If you find a dead end, then you need to back up to the logical model and see where (or if) you went wrong, again keeping at that level until you think your fixed the problem. Then another mapping iteration and so on. After a while, you'll have mapped your entire logical model and now you can start refactoring the physical model (or code if you got that far). Just remember that you shouldn't be refactoring without an automated test suite to make sure you don't break anything!
Maybe once these are truly assimilated it all becomes easier.
Yeah, and that assimilation takes time (Hal Helms said at CFUNITED this year that OO takes a year or so to learn).
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?
Yes, for the same reason that a fully normalized database isn't always the best choice. You denormalize your design to create something more maintainable (or more performant) and that, to me, is an accepted part of software design. It's about being pragmatic, rather than dogmatic. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood 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
