The MVC pattern can be visualized as in Figure 2.

Implementing MVC in CFMX requires at least three files. The Controller page (user_list.cfm, see Listing 1) is called from the browser. The Model (user_db.cfc, see Listing 2) is a ColdFusion component that's designed to be instantiated and held in memory for some amount of time. In this implementation two CFCs have a parent-child inheritance model. The CFC in Listing 2 extends and inherits the functionality of a "parent" CFC in Listing 3. The View is an included ColdFusion page (user_list. cfm, see Listing 4) that contains nested Views (view_row.cfm, see Listing 5).

The MVC Conversation
The end user initiates a conversation by creating user input. In a Web application the input might be a click on a hyperlink or a submit button.

The Controller receives the resulting request from the browser and executes at least two steps. First it creates an instance of the Model CFC in the Request scope. Next it examines the URL scope for a "sort" argument; if it exists, it passes it to the Model, modifying the Model's current state. Finally, it calls a View that's designed to output the contents of the Model. The Controller code looks like this:

<cfset request.data=createobject("component", "user_db")>
<cfif isdefined("url.sort")>
<cfset request.data.setSortOrder(url.sort)>
</cfif>
<cfinclude template="user_list_view.cfm">

When the component is first instantiated, it runs its parent CFC's constructor code (the code prior to the method definitions) and creates a locally owned variable named "this.query" as a nonquery type. When data is first requested from the object, the component sees that the query hasn't been created and runs an initialization method:

<cfif not isquery(this.query)>
<cfset this.init()>
</cfif>

<cfquery name="this.query"
datasource="myDSN">
SELECT * from users
<cfif this.sortorder neq "">
ORDER BY #this.sortorder#
</cfif>
</cfquery>

The View page is included only when the CFC instance has been placed in the Request scope. The View's first job is to create a reference to the CFC instance:

<cfset data=request.data>

The View then outputs an HTML table presenting the data to the user. Notice that it doesn't use a conventional <cfoutput> loop with a query attribute. Instead, it uses the CFC's next() and getValue() methods to retrieve data for output:

<cfloop condition="data.next()">
<cfoutput>
<tr>
<td>#data.getValue("user_name")#</td>
<td>#data.getValue("user_city")#</td>
</tr>
</cfoutput>
</cfloop>

Now let's see what happens when the specifications expand as before. When the developer is asked to support multiple devices, it's easy to develop additional View files and call them dynamically from the Controller:

<!--- Assumes a session.
device variable --->
<cfinclude template="user_list_#session.device#.cfm">

If the structure or source of the data changes, the developer modifies the Model CFC. The Model is maintained independently, and the Controller and View files are left alone. As long as the data coming from the Model matches the View's expectations, the Model's internal implementation can vary as needed.

This independence of the View from the Model, and vice versa, is known as "loose coupling." They are designed to work together, but can also work with other partner components as long as they agree on the syntax of their conversation.

Views Within Views
The View is the outward presentation to the user. A single View can represent the entire page, but it's also common to have small pieces of visual presentation nested within the larger view.

A good example of this is the common CF practice of including header.cfm and footer.cfm files to give your application a common look and feel. Both the header and footer files create browser output, so they are Views. They are then nested within a "master" view. Figure 4 is a visualization of this architecture.

Each part of the nested View outputs its result directly to the HTTP response. To get data, each converses directly with the Model instance stored in the Request scope (see sidebar). The use of nested Views is a good reason to place data in the Request scope rather than passing the CFC instance directly from the Controller into the top View, and so on down the calling chain. Since all Views get their data from the same place, they're independent of each other, and modifying one doesn't have a negative effect on any other.

In this final version of the View, I've separated the section that outputs the HTML table row into its own nested View. Listing 5 is a custom tag that expects a comma-delimited list of field names. This View connects back to the Request-scoped Model, and retrieves one field value at a time:

<cfset data=request.data>
<tr>
<cfloop list="#attributes.fieldlist#"
index="fieldname">
<td>#data.getValue(fieldname)#</td>
</cfloop>
</tr>

SIDEBAR
Passing the Model Object
There isn't a single standard for how the Model object is passed to the View. In J2EE, where JSP pages are usually used as the View, it's common to place the Model in the Request scope, as it isn't possible to pass arguments to JSP files. In ColdFusion MX you can use custom tags as Views, so it would be valid (and perhaps preferable) to pass the CFC instance to the View as a custom tag attribute.

Each approach has its advantages. If the CFC instance is Request-scoped, each nested View isn't dependent on getting its data from its parent View, so you achieve more independence. But what if each View is supposed to get a different version of the Model? In this case it's probably better to pass the specific Model instance as an attribute, achieving better control.

More About Models
Macromedia recommends the use of CFCs in CFMX whenever you need functionality that's strictly server-side. Database queries, file management functions, communication with LDAP servers, and parsing of XML files are all examples of functions that manage data, not presentation. A CFC is ideally suited for use as a Model.

In the MVC pattern the Model is the most visible to, and the least aware of, the other members of the pattern. By "most visible" I mean that it can be seen and used by a Controller or a View. By "least aware" I mean that it doesn't need to know who is calling it.

In some MVC implementations the Model is able to notify Views of changes in state. In a ColdFusion implementation the View is short-lived (it doesn't stay in a persistent scope as the Model does, or as a View would in a persistent visual application). So in ColdFusion it only makes sense for the View to make requests of the Model and not the other way around.

Imagine that you've designed your MVC application from the beginning assuming that your user data is in a database table. Now you're told that the data will be moved to an LDAP (Lightweight Directory Access Protocol) server. Knowledge of the source and structure of your user information is programmed solely in the CFC and is hidden from the rest of your application. In object-oriented terms the data has been "encapsulated."

All required changes to your application will be localized to the CFC. As long as the syntax of the CFC method remains stable, the other members of the pattern (the Controllers and Views) don't have to be modified at all. Again, maintainability is significantly improved.

It's also possible to take advantage of CFC inheritance to create a clean, maintainable architecture. Notice that the file user_db.cfc (see Listing 2) includes only the init() method. All other methods are inherited from a "super" CFC (see Listing 3). The methods in this class are common to all of my data model CFCs. It would also be possible to create sibling CFCs for reading XML files or translating Web service calls. As long as they all deliver their data to the View with the same API, the Views don't need to change.

Caching and State
State is a big deal in Web applications. Whether you need to store user information for site personalization or improve performance with intelligent data caching, ColdFusion has always made it very easy to create and read persistent data using the Session and Application scopes.

Imagine that I want to cache the "users" table in server memory. Whenever a user record is added, updated, or deleted, the cached version should be refreshed from the database.

In a typical ColdFusion application that doesn't use components, the logic and variable names would be scattered among multiple ColdFusion pages. A CFC, however, can be created in the Application or Session scope, and can store data and logic in its own properties and methods.

In my Application.cfm page I might have this code:

<cfif not structkeyexists(application, "userdata")>
<cfset application.userinfo=createobject("component", "user")>
</cfif>

As before, in the constructor code I could initialize a variable named "query" as a member of the component instance using the "this" prefix:

<cfset this.query="">

In the function that creates the query object of all users, I would first check to see whether the variable is a true query object. If it isn't a variable of type "query," I execute <cfquery> to refresh the data:

<cffunction name="init()">
<cfif not isquery(this.query)>
<cfquery name="this.query">
SELECT * from users
</cfquery>
</cfif>
</cffunction>

The cached data can be cleared within the CFC whenever necessary. For instance, this CFC function is used to update user records:

<cffunction name="updateUser">
<cfargument name="id" type="numeric">
<cfargument name="name" type="string">
<cfquery datasource="myDSN">
UPDATE users
SET user_name='#arguments.name#'
WHERE user_id=#arguments.id#
</cfquery>
<cfset this.query="">
</cffunction>

Caching logic is now restricted to the CFC. External users of the component simply ask for the data. It's up to the Model to determine whether the data should be read from database or memory. No matter how many times the data is called from various parts of the application, if the business logic or data storage mechanism changes, the programming changes will again be localized to the CFC and won't have any effect on the Views that make use of the data.

Conclusion
Every software design choice has both benefits and consequences. Adoption of MVC-style programming makes your site more maintainable, but takes more initial time and thought than simply throwing a few ColdFusion pages together.

Also, any new design pattern should be load-tested early in the development process to ensure that the extra layers of code don't end up crippling the application's performance. But the first time you make a significant change to your application and find you can do it in just a few minutes without fear of collapsing the whole house of cards, the exercise pays off huge dividends.

In this article I've described some of my own experiments with the new CFMX toolset. As I mentioned at the beginning, I'm just beginning to explore the power and flexibility of the CFC programming model. Try it out and let me know what you learn.

Resources