For that matter...

Now, once again, think about the app you just finished or the one you're working on. What if there weren't a single <CFQUERY> em-bedded in the pages that generated output and performed user interaction, would that make your development life easier?

Separation of Presentation and Content
Which bring us to the separation of presentation and content. This isn't a radical new idea (even if the same basic concepts keep resurfacing under new names). The basic concept is that your application needs to be broken into layers (often called tiers). Exactly how many layers is up for grabs (there are lots of opinions on this one, and for the most part the discussion is academic), but at a minimum your application should be broken into three distinct tiers:

1.   The back end (starting with databases)
2.   The front end (the user interface, be it Web pages, or client-side Flash, or anything else)
3.   And in the middle, the application itself (often called the business tier)

The truth is, the front end should never be tied to any particular database. Each should be free to be improved on (and changed and adapted) without fear of things breaking.

Similarly, you'd never want your business logic in the same page that generates HTML output. Why? Well, as soon as you need an alternate output format (whether it be Flash, XML, a Web service, or even a simple spreadsheet), you'll need to re-create all that logic (or patch your original file).

So, back to our example: the code both retrieved data from a table and formatted it for output. What if I needed an alternate output format? I'd have two choices. Either I'd create a second file (copying the query code) or I'd put a big <CFIF> statement around the output so it could generate both output formats.

While that may be acceptable (and even manageable) for simple code like this, imagine if the query were extremely complex and required all sorts of postprocessing. Then neither option would be really workable. What I'd really want to do is move the database-specific code out of the file that generates presentation into its own file. Then I could have two different presentation files (one for each output format) and have them use the same query by accessing the query file.

In tiered development, content and its presentation are explicitly separated, making each more manageable, more usable, and more reusable.

ColdFusion and Tiered Code
Everything discussed thus far applies to any development in any language, not just ColdFusion. But now let's focus specifically on ColdFusion.

It's been possible to write code like this in ColdFusion for a long time. Between <CFINCLUDE> and custom tags, writing tiered code has been doable. But neither option is ideal. <CFINCLUDE> is ill suited for highly dynamic content (for starters, there's no way to pass variables to an included page or to return results), and custom tags are too cumbersome (no built-in parameter validation, single entry point, can't be introspected and thus can't be shared simply, can't return results, and more).

Which brings us to ColdFusion components. CFCs are designed for just this purpose, building tiered applications. Imagine that you could take all your user-related queries and store them in a single file, then all your product queries and store them in another file, and so on.

Then, to obtain a list of users you could do something like this:

<!--- Get user list --->
<CFINVOKE COMPONENT="user"
METHOD="List"
RETURNVARIABLE=" users">

This code calls a method (a function) named List in a component named user and returns a result named users. What is in the user component? It doesn't matter. Whatever it is will be executed and a result will be returned.

Another way to invoke the component would be:

<!--- Get user --->
<CFOBJECT COMPONENT="user"
NAME="usrObj">

...
<CFOUTPUT>
<!-- Display email address --->
#usrObj.GetEMail(URL.userid)#
</CFOUTPUT>

Here the user component is loaded as an object, and a specific method in that object is then invoked - in this example, passing a user ID and obtaining the e-mail address for the specified user.

In both examples the component is now that middle tier - your presentation code talks to the component, and the component talks to the database.

All that's needed then is the component itself.

CFCs as the Middle Tier
As explained in the earlier columns mentioned above, writing CFCs is very easy. (And if you use Dreamweaver MX there's a wizard you can use that does most of the work for you.)

Look at this code:

<!--- User component --->
<CFCOMPONENT>

<!--- List users method --->
<CFFUNCTION NAME="List"
RETURNTYPE="query">

<!--- Get users --->
<CFQUERY NAME="users"
DATASOURCE="exampleapps">
SELECT EmployeeID AS UserID,
FirstName, LastName
FROM tblEmployees
ORDER BY LastName, FirstName
</CFQUERY>

<CFRETURN users>

</CFFUNCTION>

</CFCOMPONENT>

This is a complete (albeit rather simple) component. It defines a single method named List (the method used in the prior code snippets). List takes no parameters and returns a query (the same query as used above).

The preceding code would be saved as user.cfc and references to a user component would access this CFC file.

Here's the GetEMail method:

<!--- Get e-mail address method --->
<CFFUNCTION NAME="GetEMail"
RETURNTYPE="string">
<CFARGUMENT NAME="UserID"
TYPE="string"
REQUIRED="true">

<!--- Get user record --->
<CFQUERY NAME="user"
DATASOURCE="exampleapps">
SELECT Email
FROM tblEmployees
WHERE EmployeeID
='#ARGUMENTS.UserID#'
</CFQUERY>

<CFRETURN user.Email>

</CFFUNCTION>

This code would be placed into the same user.cfc file (all methods go between the <CFCOMPONENT> and </CFCOMPONENT> tags). It takes a user ID as an argument and returns the e-mail address for the specified user.

This is just the start of it. With all database queries in one isolated location, you can start getting creative. You could:

And it gets better. Dreamweaver MX is CFC aware and can automatically display a tree control listing all CFCs on your ColdFusion server. This allows users to right-click on any CFC or method to see more information about it, and even drag a method into their code to autogenerate the re-quired invocation code. All automatically, and all without having to register anything in Dreamweaver itself.

Note: There's another benefit here, Flash MX integration. But more on that next month.

What Next?
If your application contained not a single <CFQUERY>, your code would be more manageable, more reusable, and even more scalable. I only showed you components encapsulating SELECT statements here, but you'd want to create components that did it all.

Databases and database access is a good starting point. After all, it's what we do mostly with ColdFusion and CFML. But it's just a starting point. Any integration with back-end systems should be tiered, starting with databases but also including:

The basic rule is this: if it isn't tied to client code, then it doesn't belong in client-generation code. Simple as that.

Summary
Most of us write spaghetti code, and that has to change. Structured, organized, tiered code is a must. I wouldn't get too hung up on exactly how many tiers are needed and whether they conform to any specific model as long as it gets done. For starters, commit to no more embedded database calls in your output pages - put them in components. Then apply this methodology to existing code. And start thinking about applying this type of development to nondatabase code as well. ColdFusion components make this very easy (and even reward the effort with better performance), so there's no longer any excuse for not doing it. It turns out that separation can indeed be a good thing.