ColdFusion Architecture For RIAs - Part 1

This is the first of a series of four blog entries I'm writing to demonstrate CF in a RIA architecture. Each entry will take a "plain" ColdFusion application and show how it was necessary (or not) to modify the code to handle the requirements of a "Web 2.0" application. This first entry is an overview of traditional vs. next-gen web applications and is an introduction to the "plain" CF application that will be the starting point for the other three "Web 2.0" applications I describe in the next three posts.

The necessity to deploy Rich Internet (or "Web 2.0") Applications is a fact of life these days. They often deliver better ROI and competitive advantage, and today's web citizens expect and sometimes even demand a better user experience. The flash platform is, at least without a doubt in my mind, the ideal platform for delivering these applications. Some companies and developers prefer to use AJAX - and if it does what they want then that's fine for them. I'm not writing to debate the merits of one technology versus another (not today, anyway). What I want to write about is the impact that this has on the architecture of a typical ColdFusion application.

On several occasions in the past years I've written about the role of CF, in the context of next generaion web apps, changing from that of a "presentation server" that is also capable of performing business logic to that of a "service provider". For the most part this is true in the case of "Web 2.0" applications - except for those scenarios where CF is generating the RIA presentation layer (i.e. CF is creating the code for an AJAX front-end using the new CF8 CF-AJAX tags or is dynamically generating other AJAX or possibly Flex interfaces). Even then, though filling the role of presentation server, let's assume for argument's sake that CF is also filling the role of service provider. So how does all this impact the architecture of your CF application?

We'll start with a very simple address book application written entirely in CF. You can download this code at http://www.horwith.com/downloads/abook-cf.zip. To test, first extract the zip file to a web root served by ColdFusion. To set-up the application as-is, run the "create-sql-server-db.sql" file against a SQL Server 2005 database, then run "create-db-tabls.sql" against that database... create a datasource in the CF Admin named "abook" that points to the new database, then browse "populate-db.cfm" to populate your new database. All of the database related files are in the "build-db" directory created when you unzip the zip file. You can browse the application simply by browsing the "index.cfm" file in the "abook-cf" directory created when you unzipped the compressed file. There's nothing "Web 2.0" about it. There's a .cfm that shows all the entries in our address book, with links to filter by first letter of last name and links to edit records, and there's a .cfm that displays a form for adding and editting address book entries. There are also 4 ColdFusion Components, which are the "meat" of the application:

• addressbook.cfc - represents an address book
• addressbookentry.cfc - a data transfer object (DTO) representing an address book entry
• addressbookdao.cfc - the parent class of all address book Data Access Objects (DAOs)
• addressbookmssqldao.cfc - the address book DAO containing all the CRUD methods for SQL Server

Not only is there nothing "Web 2.0" about this code, but I should also state for the record that I had no intent of using it in a "Web 2.0" environment. It was actually written as part of an object orientation code exercise I conducted at Nylon Technology. This fact only makes it an ideal candidate for use in illustrating the impact of leveraging "legacy" code in next-generation applications. All of the data is cached in the session scope - the idea being that when a user logs-in, their address book(s) are loaded into the session scope and synchronization with the database actually happens behind the scenes. It's worth mentioning that to keep things simple I've taken 2 shortcuts. First, there's no actual log-in... in the real world you'd force a log-in and, at that time, select the address book IDs for all the address books owned by the current user. Second, since there's no log-in, the code is hard-wired to assume that for any request the address book ID from the database is 1. You can see this defined in the Application.cfc "onSessionStart" method.