QuackFuzed [ Ramblings of a Con..ColdFuzed Mind ]

To Gateway Or Not To Gateway?

Posted on August 29, 2007 at 3:54 PM in ColdFusion

So my good friend Charlie Griefer has finally decided to take the OOPlunge. He has started a series of posts about his OO learning expedition, aptly entitled going OO. Good reading.

Sean posted the following comment to one such post...

"You're starting down the path of the "5:1 Syndrome" where you are going to end up with bean + dao + gateway + manager/service + controller for every single table in your application.

"Whilst that may seem a common practice in the ColdFusion, it's not a good one - and since you clearly want to understand OO and write good OO code, let's at least get the word out as to why

This comment made me question my own understanding of why I do things the way I do them, which has generated this post from me.

At first, I was a bit annoyed with the prospect of questioning myself (yet again), since, when it pertains to code, I already have a natural tendency to "analyze until I paralyze". You know how that goes - the whole: "Should I -really- be doing it this way? What if it screws me up later?" argument that goes on inside one's head. However, after a bit of time, I realized that Sean was just trying to make sure that people don't blindly do something, but rather have an understanding of why they're doing it. So, here is what I typically do, and my understanding of why I do it.

My "beans", which I typically refer to as core objects, have absolutely no knowledge whatsoever of the database. I don't want them to, since I should be able to use these same beans over and over again across multiple applications. Also, these core objects may or may not actually represent a single table in the database. Obviously I am referring to generic objects (e.g. person, user, email, etc) as opposed to application-specific objects (e.g. MyAppWidget). If these beans had any database knowledge, (a) they would not be useful across multiple applications, and (b) they would more than likely be tied to a particular database technology (e.g. MSSQL vs. MySQL).

For me, knowing that both (a) and (b) above are problematic to the way that I want to handle development, the argument of whether or not to place CRUD methods inside of my objects is settled. So then, the next question that Sean's comments brought to light was:

"Do I really want/need separate DAO and Gateway objects?"

My answer is a resounding "YES!", and here is why...

I don't know about you, but the entire reason that I began to seriously look at OO was because I wanted easier maintenance down the road. It was *not* because I couldn't create applications that did what I needed them to do, and it was *not* because the applications that I wrote did not perform efficiently. Therefore, I personally like my DAOs to handle persistence for a single record in the database. For me personally, this keeps my persistence logic clean, and -very- easy to maintain.

So then, since I do not want my DAO to deal with multiple records, that leads me to having a Gateway object to handle such tasks.

One of Sean's points was that when blindly heading down the "I gotta have my beans, my DAO, and my Gateway too!" path, that one ends up with 5 (or more) objects for every table in the database. I thought about that statement for quite awhile before it sunk in: Yes, if you are building from the database out, and you blindly believe that philosophy, you will indeed end up with something like a 5:1 objects to tables ratio.

However, if you are building an OO application, the database should be the farthest thing from your mind when you initially sit down to create your object model. This has been the single most difficult procedural habit for me to break - one with which I still sometimes struggle.

In days gone by, the database was *always* the very first thing that I started with (after finding out what the client needed the app to do). So ignoring the database to create my object model was a very foreign concept to me.

So then, what happens if I build my object model first, and the database design later? Well, for one, you end up with Gateway objects that may or may not have methods that deal with one single table. I have found that it is rare that I have a Gateway object that deals with a single table. In other words, there are a number of tables that have no Gateway object whatsoever (of their own).

"Yeah," you say, "but what benefit does this provide?"

Well, let's say that your company has grown to the point that a new DBA is hired in, and you no are no longer working with the database. This new DBA wants to change the design of the database. No problem. All you need to do is update the SQL in the affected Gateway(s)/method(s), and you're done. There's nothing else to even concern yourself with.

I am by no means suggesting that -not- using a Bean > DAO > Gateway architecture is wrong. I am simply stating that there is a very good reason *to* use such an architecture, provided that you know and understand why you're doing it.

As others have said, simply having a batch of CFCs that are named MyObject, MyDAO, and MyGateway in your application does not make it an OO application. :-)

Comments

(Comment Moderation is enabled. Your comment will not appear until approved.)

On 8/29/07 at 9:58 PM, Sean Corfield said:

And another point to consider is that the "DAO" (in CF terms) often goes away completely if you use an ORM since basic CRUD is handled automatically.

I find more and more that I don't have DAOs in my apps because I use Transfer and it encapsulates that behavior centrally for all objects. At most I may have a few methods in my gateways that wrap the use of Transfer to provide a consistent, gateway-only API.

In other words, as far as I'm concerned, the gateways are fine and it's the (CF) DAOs that I've moved away from...

On 8/29/07 at 11:30 PM, Matt Quackenbush said:

Sean,

Thanks for the reply. I almost put in the post the point about an ORM, as I am in love with Transfer myself, but figured it was another topic. I now see that it wasn't gateways per se that you were pointing out, but rather the (CF) DAOs, as it were. Since you didn't rip apart my post, I feel confident again that I am still on the right track in my own OO (as it relates to CF) adventure. :)

[Add Comment]