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/