Presenting on OO - Should I show the "Gateway" pattern?

[John Whish]

Hi all,

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]

Hi John.

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.

 

Alan

---

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]

> 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.

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]

> 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

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]

Hi Alan, personally I like getting multiple rows as a query and then looping over them to convert them to an array of objects so my View never sees the query object, but I know that that is not ideal in terms of performance. I think the answer may be that I need to present all options and then let the individual developer decide...

[Alan Livie]

@Massimo, true but then we have some business rules living in the domain 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

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]

Sounds good.

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.

 

Alan

---

From: John Whish <john....@googlemail.com>

To: cfc...@googlegroups.com
Sent: Monday, March 2, 2009 10:13:43 AM

Subject: [CFCDEV] Re: Presenting on OO - Should I show the "Gateway" pattern?

[John Whish]

Hi Massimo, I like the database approach and it's one I've used. I consider it a pragmatic solution rather than a bone-fide pattern as you end up duplicating code :)

The Table Gateway pattern as I understand it is pretty much the same thing 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. 

[Massimo Foti]

> The Table Gateway pattern as I understand it is pretty much the same thing
> 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]

> @Massimo, true but then we have some business rules living in the domain
> 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]

Thanks for the links Massimo :)

[John Whish]

I know this is digressing and likely to start an argument, but having read the links I don't see that DAO and Table Gateway are that different. Both deal with multiple rows and have select, update and delete the main difference is that DAO can also create. Row Data Gateway seems to be closer to how CF developers think of the DAO.

Would you agree with that?

P.S. It's interesting now that I'm really starting to dig into this stuff how much I have just accepted :)

[Bob Silverberg]

I figured I'd throw in my $0.02; I see the gateway as a component that
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]

Hi Bob, your 2c is more than welcome :)

What I'm finding is that the way I do things (and I see others doing it) is a pragmatic approach to OO in ColdFusion. What I would like to do in my presentation is show the classic patterns and then show the problems and the solutions that ColdFusion developers have come up with. I really want people (and myself included!) understand the various approaches and the pros and cons of each + work around methods. Too many people seem to think (and I did when I started out) that DAO and Gateway is the one true OO way.

From what I've read, Gateway simply means iteracting with an external resource. 

It's amazing how much Transfer does!

[Sean Corfield]

On Mon, Mar 2, 2009 at 1:54 AM, John Whish <john....@googlemail.com> 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

[John Whish]

Thanks for the feedback Sean,

Although I'm not a OOP expert I've never been comfortable with using a DAO and a Gateway object, which is why I posted this question as to whether I should mention it in the presentation. 

As you said the gateway and DAO technique is easy to understand, (you're a victim of your own success!) trouble is a lot of people stop at the point without knowing about why it is done like that or other patterns they could use. You've also raised another really good point, that I see a lot of which is to use one class per table. Perhaps I should do the Data Mapper pattern as well!

Maybe I should just wait until you visit Devon and get you to explain it all :)

- John

[Jaime Metcher]

John,

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]

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

---

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]

@Jamie, I've been concerned about that as well. I really want to go slow and steady with my presentations and give members a good grounding in concepts and principles, but the group just wants to get on and build something! I want to keep them interested so I feel I ought to be guided by what they want...

@Alan, data mapper is definitely something I want to cover as you're spot on that the business objects should not know anything about the database schema only the object's properties. Transfer does this really well.

Keep you thoughts coming. It's all really useful food for thought. I might go back to my group and just tell them that they'll have to wait for the ORM stuff :)

[Peter Bell]

Actually, for anyone serious about hibernate, I'd recommend Java Persistence With Hibernate: 

http://www.amazon.com/Java-Persistence-Hibernate-Christian-Bauer/dp/1932394885 

You learn a *lot* about ORMs in general as well as the details of JPA and Hibernate. It was the precursor to this that I read a few years ago when I started working on my own baby ORM and it really helped to explain all of the concepts.

Best Wishes,

Peter

[Barney Boisvert]

People will still care about DAOs; separating persistence code is
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. 

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 :)

[Jaime Metcher]

Barney,

+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]

On Tue, Mar 3, 2009 at 9:14 AM, John Whish <john....@googlemail.com> wrote:
> 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.