On Mon, Mar 2, 2009 at 1:54 AM, John Whish <[email protected]> wrote: > do do ActiveRecord, DAO, FlyWeight and Iterator patterns (although it > might have to be split over 2 presentations) and introduce the > "gateway" as a ColdFusion specific pattern that is used for speed > rather than being OO.
Since I'm sort of responsible for the separate DAO / Gateway nonsense in CF - due to a recommendation I made in 2003 in the Mach-II Development Guide - I'd really like to see it completely eradicated! I made the recommendation at the time when OO was completely new to (most) CFers and felt it would be a good "reminder" to get them to think of objects as single DB rows and queries for aggregate operations so they wouldn't be tempted to use a query for a single row or, worse, an array of objects for giant query results (due to performance). It was a reasonable stepping stone at the time but things have moved on and I try very hard now to encourage CFers to learn from mainstream OO design patterns and therefore explain that DAO (in Core JEE Patterns) and the Table Data Gateway (in more general pattern material) are really the same and as long as folks understand *why* we don't generally use arrays-of-objects, it's actually fine to put find*() methods (returntype="query") in the same data layer object as the CRUD stuff (which operates on a single row / object). The reason for pushing this unified approach is that it is easier to avoid the "5:1 Syndrome" (bean + dao + gateway + manager/service + controller) by having a DAO that operates on an object and its closely related objects for both single and multiple record operations, dividing the application by logical grouping rather than just the five objects per table approach. In my apps, my controller deals with an "area" of the application, usually dealing with multiple object types, my service/manager object deals with a functional subsystem, again with multiple object types - and focusing on collaborative functionality that doesn't fit in a single object, my data gateway deals with a related group of object types and my beans have as much logic as they need to do their own job. Also, if a DB table is used only in conjunction with another (e.g., UserStatus used with User) then I don't have a UserStatus bean - the status is subsumed into the User bean and you can ask if the user.isActive() or user.isPending() or whatever (and using onMissingMethod() allows you to add arbitrary status values without adding more methods if you care about that sort of thing). So, fat beans, thin services and controllers, and a "sensible" data layer. Let's all work together to kill off the old-fashioned and unnecessary separation of DAO and Gateway and get CF usage more inline with "common wisdom" in the broader patterns community. -- 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 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 -~----------~----~----~----~------~----~------~--~---
