Architecture

Digg This!

In any membership organization with many in-house applications, the ability to share members' data among applications is vital. Previously, applications would duplicate functionality or make members leave one application to update their new address. This didn't work well for members, nor was it easy to maintain by developers.

Using a new framework, CFMVC, allowed us to make improvements. Our new membership system will allow our paper submission application to let members change their institution with the same front and back end code the membership application uses.

In developing a new framework we needed it to handle the integration of over twenty different databases and applications, work with multiple developers, have low processing and be straightforward. We achieved it by utilizing the benefits of ColdFusion and the Model-View-Controller (MVC) architecture.

ColdFusion

Though it's arguable whether or not ColdFusion is an object-oriented development environment, it does support many object-oriented features and has many constructs that allow developers to reuse code and functionality. ColdFusion Components (CFCs) are ideal for all data interactions and business logic while normal ColdFusion pages, User Defined Functions (UDFs) and Custom Tags are ideal for handling display portions.

All applications, regardless of size, contain the following pieces:

• There will be some way of displaying information to a user - most likely, for ColdFusion developers, via a Web browser.
• Another piece will process any changes the user makes generally by writing to a database.
• A third piece will direct the user to a new item to be displayed.

Sound like the pieces of your applications? Now it's not just web applications that have these tiers, pretty much all applications contain them - even going back to the days when computers were the size of rooms and disco was cool for the first time.

Model-View-Controller

The Model-View-Controller (MVC) architecture was designed over 25 years ago by Trygve Reenskaug. Originally designed for Smalltalk programmers, it has been used in many languages from Visual Basic to Java, and is especially common among Object Oriented programmers. Companies embracing it include Apple and IBM.

MVC separates an application into the three pieces or tiers mentioned earlier. What exactly does MVC consist of?

• The model layer handles all core data interaction whether with a database, XML files or any other data store along with other business interactions.
• The view layer displays data to the user.
• Any action the user takes goes through the controller layer, which calls the needed parts of the model layer before calling the next view layer to display.

Make sense? If not, bear with me and it soon will!

By combining ColdFusion's best practices and the proven architecture of MVC, a framework emerges that modulizes code and allows for it to be used in multiple applications. (Benoit Hediard also has a similar idea for merging together MVC and CF, see www.benorama.com.)

Tying Together CF and MVC

Where does ColdFusion code live and where does it use components, pages and custom tags?

Model
Most applications use at least one database. The model tier retrieves data from the database, stores this data, and provides functionality for interacting with the database. If your application uses text files or some other data storage mechanism, then your model tier will interact with that entity. My MVC implementation involved creating an entity CFC for each table in the database (for example, PeopleEntity.cfc) that handles select (get), update and insert statements (set) and delete if required. A utility CFC is used when returning multiple records, joining other tables and processing functions that require more than one entity, like adding a new member - which requires inserts into a members and an addresses table. All code in the model layer must be written so it can be reused in other applications and should not use session, application or request variables; rather, values should be passed in via attributes. Other CFCs, to be shared, are also added in the model layer for e-mail, SOAP calls, LDAP, and so on.

Each CFC should be a object and contain only functions (methods) that relate to it. Functions should either perform one action only or be a wrapper function and call other functions.

View
The view tier is where all display files reside. Custom tags are used extensively for presentation code and can be called from any application if needed. Like the model layer, they must not include session, application or request variables. For some presentation purposes UDFs may also be needed.

We did two things that are not part of MVC but were needed for ColdFusion implementation. First, all forms use the post method and custom tags that contain a form accept two attributes: formAction and formMethod, which are placed in the form to pass data to the correct controller. This allows for calls from anywhere and the capability to post to anywhere. Second, all applications have at least one applicationSkin file (see membershipSkin.cfm) in the view layer to allow for an application appearance to be set. Multiple skins can then be used if, say, an admin version is intended to look different to a normal version.

Controller
The controller tier is on the web root and has no pretense of being reused. Indeed they should only be used by the application. There are two types of controller files: view-controller and model-controller. View-controller files call code in the view tier and sometimes add customization themselves. Model-controller, as the name suggests, handle all interaction with the model layer but it's important to remember that code here is not intended for reuse and extra features for this application can be added for example an e-mail or calling a web service.

As part of the ColdFusion implementation, view-controller files are standard cfm files that call custom tags. Model-controller files are CFCs, are accessed remotely but as are below an Application.cfm (or Application.cfc) file fit into whatever security system an application deploys. Once a model-controller file has finished processing, it uses cflocation to call the next view-controller file to ensure that data is processed only once if a user reloads.

If you have trouble separating your files into their appropriate areas of the MVC framework, the code in that file is probably doing too much. Try breaking it down into smaller parts.

Folder Structure

Where does all this code sit? As controller files are used only by the application they all belong in the application web root, i.e. webroot/membership/. View-controller files, one for each area of the application, sit in this folder (see Figure 1). This allows for freedom in naming and short URL's. Features that apply to that area only, such as navigation, can also be added easily. Model-controller files are all placed in a controller folder i.e. webroot/membership/controller/.

The rest of our code, in the model and view tiers, is intended to be shared. Below the webroot we set up a folder called cfshare and within that a CFC, tag, and UDF folder (see Figure 2). A merging of ColdFusion, MVC and our desire to share code amongst applications led to such a folder set up. All model files are CFCs leading to a natural home for them, so beneath the CFC folder an additional folder is created for each application to store Entity, Utility and other components.

A similar set-up occurs for view files, all of which are custom tags. Likewise within the tag folder is an additional folder for each application. For the times when UDFs are used they follow the exact same structure under the UDF folder.

To make accessing easier in our code, a ColdFusion mapping is set up to the cfshare folder. Once achieved to access the peopleEntity in the model tier simply call the component:

<cfinvoke component="cfshare.cfc.membership.peopleEntity" method="init"></cfinvoke>

And to access the applicationSkin (using CFMX 6.1):

<cfimport prefix="/cfshare/tag/membership/ " taglib="view">
<view:membershipSkin>
</view:membershipSkin>

Or for 6 and backwards:

<cf_membershipSkin>
</cf_membershipSkin>

Code

Let's look at two code examples, which can be downloaded from www.sys-con.com/coldfusion/sourcec.cfm; first the display page for a member to join and second the processing of the collected data.

Code Example One: index.cfm
The first example uses a view-controller called index.cfm.

We start by importing a taglib and giving the prefix of view to enable the calling of custom tags (such a method shows future developers exactly where the custom tag is). Then we param the URL display to a default value of "join". Next we open up the membershipSkin call inside of which is a cfswitch statement which will call the desired display. The default value of join is picked and the "people" custom tag is called with some variables passed in. The cfswitch statement and membershipSkin custom tags are then closed.

Let's step back and look at the people custom tag. First it performs a check to see if it has already been called and if so exits, to prevent duplicate output. Then it calls the peopleEntity cfc and outputs a simple form to allow for the collecting or editing of data. The three attributes it accepts are important: nextAction and nextMethod work in tandem - nextAction contains the path to the processing controller ("controller/membershipController.cfc" in this case) and nextMethod is the name of the function that will be called in the controller file. Passing in a value of -1 for peopleID allows for blank values to be created, but if a value of a real member had been passed in then those values would have been displayed.

Code Example Two: process-controller
How does this get processed? This is an example of a process-controller with the membershipController.cfc being called.

The nextMethod attribute in the people custom tag was set to a hidden field called method which when passed to a cfc remotely will trigger that a function of the provided name. For this example it is join. The access attribute in join function is set to remote to allow for it to be called over the web. The function creates an object to the peopleEntity in the model layer and then calls the set function with the passed in values. The peopleEntity then either runs an update if a valid peopleID is passed or an insert. Just like that, we have a new member! The join function then uses cflocation to relocate the user to the next page.

Summary

The CFMVC framework discussed above is based on a proven, successful architecture in MVC and has a low processing overhead for ColdFusion. The effect of splitting an application into tiers - model, view and controller - allows us to write applications that can share both data and functionality easily. But the benefits will also extend to completely standalone applications.