In the more modern day ColdFusion development, we tend to rely heavily on various Design Patterns to automate or "template" our daily coding chores. The patterns most frequently touched on are the Data Access Objects (DAO), DataGateway (DG) and VO (Value Object) ­ or ­ Bean (VO with setter/getter routines).

I've often used them, but can't but help get the feeling that they are probably not suited for the ColdFusion Development world as to me; their reasons for being used aren't valid enough to warrant using them blindly.

I mean, why Use a DAO?

I'll attack DAOs first, as these are one of the core primitives found in most frameworks.

The concept of a DAO is as most already know, to allow the four key actions to take place (CREATE, UPDATE, DELETE, READ). In doing this, along the way we are supposed to accept "arguments" of each specific type (i.e., CustomerID is Numeric?).

If that succeeds, the logic to perform one of the above actions commences, and as a result we have a success result.

Yet, what are we really achieving by having a DAO in place? In that is it about strict typed variables or is it about housing logic inside a CFC for safekeeping. At the very least that's all we are really doing is preventing data that has the wrong type, being inserted into a database or xml packet.

What if we were to say, use an XML Schema to dictate this?

In that using a "TableAdapter" object, we feed in arguments or serialized object, which the TableAdapter dissects, validates and allows passing otherwise it throws an exception.

Immediately one thing springs to mind, in that it breaks encapsulation of knowing what variables are passed in and out of an object, in that they become "unknown."

Which is true, how are we to know that CustomerID is String or Numeric?

We, the developer would look this up under the various documentation tools out there such as CFCDoc, which tells us exactly what's coming in and out (i.e., how to implement).

Yet, are we not getting in danger of coupling our entire business logic with say our database? What would happen if down the road we change CustomerID from Numeric to String (i.e., AutoNumber gets replaced with UUID) what then? How do we adjust our rules and policies to cope?

We could make a ruling, which simply states that all "ID" fields are "Strings" regardless, and only when they get tucked away inside our nominated database, that actual type conversion kicks in. Yeah, that'd work but where does that rule end?

This is probably a problem used in most other languages, and there are other ways to overcome this (i.e., overloading a method for one) ­ yet ­ we are in ColdFusion, not one of these languages.

This line of reasoning is the foundation of why I disliked in many ways the concept of DAOs as they are "too" specific in terms of data typing. It's too easy to let the compiler take care of the "rulings" on what type of variable should be sent to the view.

How about an alternative solution? In that what if we put together an object, which we could ask should we need to know what type of variable it is?

In that, what if an object called "DataTable" existed, and inside that we had another object (composition) called "DataRow," which essentially we ask to know what "type" a column is.

This concept is loosely borrowed form Windows .NET 2.0's "DataSets."

Essentially all your "Database" activities are stored inside an XML Schema, which essentially defines how and where data gets stored and what "type" they are expected to be stored in.

Furthermore, it's not limited to "Databases." It's also used for "Files" (XML, CSV, MS Access etc.).

The point is this that by hard coding our persistence storage via DAO, we are really shifting our approach in terms of defining the rules required to be in place before data is persisted. If these rules change, it can be an achievement unto itself to go through code and adjust properties/arguments to suite.

Then there is the risk of having a mutipersist-based application, which results in duplication of code in the way of DAO just because there are different types for each persistence technology (MySQL versus Oracle, etc.).

Its hard post to swallow, I do admit that as every bone in your OOP bodies would be fighting tooth and nail that this is totally against the OOP grain, which I do agree, except we are in "ColdFusion" ­ a point that I cannot stress enough. ColdFusion isn't sophisticated enough to cope with the rulings of its foundation (J2EE) unless you introduce specific Java hacks. If you introduce JAVA into the equation, then yes we are in a whole new discussion, but most don't use JAVA as their buffer between ColdFusion and a Database.

This brings me to my original question, why use a DAO? Same question goes for a DG, why Use them?

In most cases, what's the difference between a "GetPersonByEmail" and "GetPersonByID" and how would you store that principal concept in a DG component? Smart answer would probably be two separate queries, with two separate "WHERE" statements in SQL terms.

Yet, what happens if we were to drop a field from the equation or better yet, introduce one?

Those of you who have used DGs and DAOs in large applications will know what I'm talking about, in that it's "a lot of work" to get all those arguments in place throughout the code base.

To me, there is an alternative and I'm currently hacking away at it. It simply involves XML to describe how my persistence gets stored and what constraints are in place should they arise are declared via XML.

A Value Object though is a hard one, because they really only serve an "emulated" approach, in that the CFPROPERTY tag really a has purpose other than to describe what potentially the variables inside a CFC will be ­ yet ­ they don't enforce such rulings.

Nope, to me ColdFusion is great, but it's not advanced enough to warrant the patterns such as DAO and DG.

How's that sit with you?

This blog is reprinted with the author's permission and appeared originally on www.mossyblog.com/archives/553.cfm.