Presenting on OO - Should I show the "Gateway" pattern?
John Whish
I've started doing a 00 101 course for my CFUG, part one went well and
the feedback was that they want to know about the persistence layer
next.
I want to cover the main patterns and emphasise that there are
multiple ways to do it (not just DAO, Bean and Gateway). I'd like to
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.
I did the classic example of showing someone's age in my first
presentation and said how you should avoid putting functionality into
the view, however if I show the "gateway" approach, I'll be back to
putting it in the view. That just doesn't feel right to me when I'm
trying to preach good practice.
Thoughts appreciated :)
Alan Livie
The gateway would return a query with dob column.
Its then up to you how you approach it:
a) A big array of objects all with calcualteAge() or getAge() methods
b) An IBO / Iterator object with calcualteAge() or getAge() methods
Both ways avoid the view knowing too much.
From: John Whish <john....@googlemail.com>
To: CFCDev <cfc...@googlegroups.com>
Sent: Monday, March 2, 2009 9:54:17 AM
Subject: [CFCDEV] Presenting on OO - Should I show the "Gateway" pattern?
Massimo Foti
> multiple ways to do it (not just DAO, Bean and Gateway). I'd like to
> 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.
Just as a side note, database Gateway isn't CF specific, it was already
covered by Fowler in "Patterns of Enterprise Application Architecture", back
in 2002:
http://www.amazon.com/exec/obidos/ASIN/0321127420/
----------------------------
Massimo Foti, web-programmer for hire
Tools for ColdFusion, JavaScript and Dreamweaver:
http://www.massimocorner.com
----------------------------
Massimo Foti
>
> a) A big array of objects all with calcualteAge() or getAge() methods
> b) An IBO / Iterator object with calcualteAge() or getAge() methods
c) A database's view that that returns the age as calculated field :-))
Of course solution c doesn't fit more complex/sophisticated needs, but for
something that simple is still a viable solution.
John Whish
Alan Livie
I now prefer all the business rules in the domain model and leaving the db to just look after its schema constraints etc
Alan
From: Massimo Foti <mas...@massimocorner.com>
To: cfc...@googlegroups.com
Sent: Monday, March 2, 2009 10:07:36 AM
Subject: [CFCDEV] Re: Presenting on OO - Should I show the "Gateway" pattern?
Alan Livie
I would throw 'lazy loading' in your presentation too.
ie no point in getting 200 OrderItem objects when the view only needed the orderRef from the Order. When the view asks for getOrderItems() you can do the big lazy loading of the array.
Subject: [CFCDEV] Re: Presenting on OO - Should I show the "Gateway" pattern?
John Whish
Massimo Foti
> as the DAO pattern. Both can be used for multiple rows. Please correct me
> if
> I'm wrong. The CF community seems to have adopted DAO = single row,
> Gateway
> = multiple rows.
Fowler talks about Table Data Gateway plus Row Data Gateway, and consider
DAO quite a different beast. I tend to agree with him.
http://martinfowler.com/eaaCatalog/
You will not find DAO on that book because it was already covered elsewhere,
like here:
http://www.corej2eepatterns.com/Patterns2ndEd/DataAccessObject.htm
Hope it may help
Massimo
Massimo Foti
> model and some in the database.
>
> I now prefer all the business rules in the domain model and leaving the db
> to just look after its schema constraints etc
I understand your point, but we are walking a thin line, is age a "business
rule" or it's just data?
Again, I am talking only about something as simple as age calculation, more
complex stuff definitely belong to business rules.
Massimo
John Whish
John Whish
Bob Silverberg
interacts with your persistence layer (or _is_ your persistence
layer), and therefore do not make a distinction between gateway and
dao. In my usage, the gateway is responsible for interacting with
both single rows (CRUD) and multiple rows.
To me the purpose of the gateway is to encapsulate database access, so
that if anything changes in your persistence layer (e.g., moving from
hand-coded SQL to an ORM, switching ORMs, changes to internal database
structure, etc.) the only component that will be affected is the
gateway.
I'll admit I came to this through the use of Transfer, which doesn't
really require that you have DAOs at all as Transfer does all of that
stuff for you. My code evolved from having references to Transfer
(which is my persistence layer) sprinkled throughout my services,
gateways and domain objects, to my current situation in which all
references to Transfer are in my gateways, thereby encapsulating
access to my persistence layer.
Just thought that you might want to consider that point of view in
addition to those already discussed.
Cheers,
Bob
Bob Silverberg
www.silverwareconsulting.com
John Whish
Sean Corfield
> 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
John Whish
Jaime Metcher
Can I just throw in the cautionary note that the persistence layer is often
where *all* the design compromises end up, and especially in ColdFusion is
where the non-OO world really refuses to be ignored. Because we all spend
so much of our time with data-centric apps you've got to cover it, but I
would always be saying up front that this stuff is not really where the OO
rubber hits the road, it's actually about the worst place to start when
learning OO, and a student should definitely not be extrapolating what we do
in the persistence layer into a set of general OO design principles.
Jaime
> -----Original Message-----
> From: cfc...@googlegroups.com
> [mailto:cfc...@googlegroups.com] On Behalf Of John Whish
> Sent: Monday, 2 March 2009 7:54 PM
> To: CFCDev
> Subject: [CFCDEV] Presenting on OO - Should I show the
> "Gateway" pattern?
>
>
Alan Livie
You just create a database and forget about it. You focus on your domain model, adding a few Hibernate annotations along the way and when you call save() in your Hibernate session it creates tables, columns and saves all the data. Inheritance hierarchies etc not a problem.
If cf9 can work with Hibernate in the same way (maybe annotations in cfscript and/or a new attribute on the cffunction tag) then in a year or two no one will even care about DAOs and Gateways.
If you want to understand things like Data mapper, Unit Of Work etc to get an idea of what Hibernate is doing then read Fowler's Patterns Of Enterprise Application Architecture ... then be thankful someone else has done the ORM work because it looks like a complete nightmare trying to build an ORM!
From: Jaime Metcher <jaime....@medeserv.com.au>
To: cfc...@googlegroups.com
Sent: Tuesday, March 3, 2009 12:07:02 AM
Subject: [CFCDEV] Re: Presenting on OO - Should I show the "Gateway" pattern?
John Whish
Peter Bell
Barney Boisvert
still useful, it's just very different from CRUD style code. But
you're right, you set up your DSN, point Hibernate at it, and you only
think about objects instead of the DB. I'd highly recommend everyone
that does OO-ish CF to take a good hard look at Hibernate. Pick up
some example code and play around with it at least. It's an amazing
piece of software, and has so many little things to teach developers,
even if they're not going to be using it in "real life". In
particular, the fact that "you should never build ORM, it's too damn
hard, and there are already existing solutions." :)
cheers,
barneyb
On Mon, Mar 2, 2009 at 11:21 PM, Alan Livie <alan...@yahoo.com> wrote:
> I've been playing with Groovy and Hibernate for about a week now and what is
> brilliant about it is when building something from scratch you no longer
> think about the db in the way you do usually.
>
> You just create a database and forget about it. You focus on your domain
> model, adding a few Hibernate annotations along the way and when you call
> save() in your Hibernate session it creates tables, columns and saves all
> the data. Inheritance hierarchies etc not a problem.
>
> If cf9 can work with Hibernate in the same way (maybe annotations in
> cfscript and/or a new attribute on the cffunction tag) then in a year or two
> no one will even care about DAOs and Gateways.
>
> If you want to understand things like Data mapper, Unit Of Work etc to get
> an idea of what Hibernate is doing then read Fowler's Patterns Of Enterprise
> Application Architecture ... then be thankful someone else has done the ORM
> work because it looks like a complete nightmare trying to build an ORM!
>
> Alan
--
Barney Boisvert
bboi...@gmail.com
http://www.barneyb.com/
John Whish
I'd highly recommend everyone that does OO-ish CF to take a good hard look at Hibernate.
Jaime Metcher
+1. You'll always need some variant of a DAO. There comes a time in any
database driven app where you can issue a query with two joins, or navigate
over object arrays with hundreds of thousands of items. The query wins, and
you need a DAO to deal with that.
However, there's enormous variation in how DAOs can be provided. In my
Hibernate models I attach a thing called a "Finder" to every collection of
domain objects. You give it a set of criteria and it returns a list of
objects. The default implementation is to translate the criteria into a set
of calls on the Jakarta CollectionUtils/BeanUtils library, which essentially
iterates over the collection and returns what you want. Up to this point,
the domain model is completely independent of the database and can be unit
tested with no database in place. However, for a given collection I can
specify a finder subclass that turns the abstract criteria into a Hibernate
Criteria query instead, or a SQL query, or even do a mix of all three
approaches. This finder subclass is a DAO, but no external object knows or
cares - there's no object that thinks it has a DAO.
So far out of about 80 classes, I've only needed two DAO-style finders - but
in those cases, I *really* need them.
Jaime
> -----Original Message-----
> From: cfc...@googlegroups.com
> [mailto:cfc...@googlegroups.com] On Behalf Of Barney Boisvert
> Sent: Wednesday, 4 March 2009 2:33 AM
> To: cfc...@googlegroups.com
> Subject: [CFCDEV] Re: Presenting on OO - Should I show the
> "Gateway" pattern?
>
>
Sean Corfield
> Rightly or wrongly I'm waiting to to see what CF9 brings to the table later
> this year with it's ORM capabilities. I think it may be the push that CF
> developers need to take the leap of OO faith :)
I'll also plug Barney's cfGroovy project and cfHibernate plugin which
allows you to write persistent Groovy entities and use them easily
from within CF.