CEP Breaking News, Articles, Feature Stories and Blog Posts

CEP on Ulitzer

Subscribe to CEP on Ulitzer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get CEP on Ulitzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

cep Authors: Tony Shan, Liz McMillan, Bob Gourley, Charles Rich, AppDynamics Blog

Related Topics: ColdFusion on Ulitzer

CFDJ: Article

ColdFusion Developer's Journal Special "Frameworks" Focus Issue: SAM

Reengineering the CF Pet Market with Sam – a more sensible code base

I've been fairly outspoken for quite some time now about the fact that I don't subscribe to any one framework. I've also spent many years refining what's proven to be the best methodology possible for developing ColdFusion applications. I recently promised my boss that I would learn and evaluate several of the popular ColdFusion frameworks.

If I couldn't find one that I felt good about recommending as our standard platform for development, I would formally document the methodology that I use for designing and developing applications. After evaluating several popular frameworks and coming to the conclusion that no one framework would ever meet all of my requirements, I went a step further and began promising to publicly release my methodology.

When I decided that we should have an issue of CFDJ entirely committed to showcasing the same application implemented in each of several popular frameworks, I knew that it would be the ideal opportunity to show developers what an application built using my methodology might look like. There's been some speculation about this methodology, which people have been referring to simply as "Simon's methodology." Some people have even made the assumption that it's actually just a "framework in methodology's clothes" and not a methodology at all, which is interesting given the fact that to date there's been no documentation about it whatsoever. I'm still not quite ready to release the formal documentation, but I will publish it online very soon and I will also be releasing a book on software architecture that is a detailed teaching of this methodology. I am, however, happy to publicly give a name to this methodology for the first time... "SAM."

SAM stands for "Sensible Assembly Methodology." I named it this because it is a methodology; one of its main objectives is to build applications by assembling standalone APIs; and it results in a code base that is, in my opinion, easier to follow, maintain, and extend... in other words, a more sensible code base. I had to resist the temptation to call it "Sensible ColdFusion Assembly Methodology" because as funny an acronym that I thought "SCAM' would be, I thought it'd be best if I tried to avoid tempting any naysayers too much. SAM is a combination of the ideas and techniques that I have found most useful in the real world - ideas that are borrowed from object oriented-programming, aspect-oriented programming, streamlined object modeling, and personal experience. Rather than just write about the rules that govern this methodology, I've re-architected the CF Pet Market application much the way it would look were I building it from scratch using SAM, and will explain some of the core ideas behind the methodology while using this CF Pet Market code for illustration. Those of you who are interested in learning more about the methodology should keep an eye on my blog (www.horwith.com) - I will be announcing the availability of the SAM documentation there first.

The primary objective of application development with SAM is to create a code base that is portable and easy to follow, maintain, and extend. This idea does not just apply to the application as a whole, but to all of its individual parts as well. This is achieved by developing each aspect and domain object as an API - a standalone module with an easy-to-use interface. A typical API consists of two files: an object (ColdFusion Component) and a custom tag. Only custom tags interact with CFCs, and only CFCs perform server-side business logic. This results in browsable pages that usually consist of little more than a few custom tag calls. This approach ensures the separation of client-side controller logic and presentation tier code from business logic, makes the CFCs much easier to use since a developer need only call custom tags to leverage application objects, and results in well-modularized code that is very reusable, including from one application to the next. Unlike frameworks, SAM has no core files, but it is likely that each developer who uses SAM will have a personal library of APIs and files that they reuse from one application to the next.

Every application built with this methodology is object modeled first, then implemented in code. SAM has a well-defined development process, very similar to FLIP (Fusebox Lifecycle Process), but describing this is beyond the of scope of this article as is object modeling; however, for those of you familiar with UML, think of an object model as being very similar to a UML class diagram. SAM uses a school of thought on object modeling applications called "object think" - it's a set of rules that govern how to represent entities and assign responsibility to objects. Let's look at the code in order to see how some of these ideas are put into practice.

The original application created an "extensions" directory above the wwwroot. This is fine but I prefer, at least in development, to keep all of my code beneath the Web root - this is simply more portable. The "extensions" directory has a "customtags' and a "components" subdirectory. There's one file in "customtags" and the "components" directory contains only a "petmarket" subdirectory (with five CFCs and a "_product" subdirectory containing one .cfm file). You can see the entire directory tree created by unzipping the original application shown in Figure 1. To make things more portable, I created a "customtag" directory and a "cfc' directory beneath my wwwroot directory. The CFC directory has no subdirectories and contains only ColdFusion Components, and the customtag directory contains only custom tags. I also created a "css" directory because moving the styles into their own files in their own directory structure makes the code easier to maintain. The original application had all styles defined in a <STYLE> block inside of the default page wrapper tag (I moved this block into a CSS file, which I put in my "css" directory). The directory structure for the SAM version is shown in Figure 2. Notice that there are now six directories as opposed to the original eight, and that everything other than the "db" directory (which has only database files) is nested beneath the "wwwroot". Now let's examine the files that are in the SAM version and compare them with the original application.

I stated earlier that with SAM, object model the application first. Figure 3 shows the CFC files that were in the original application's "components/petmarket" directory. Figure 4 shows the CFC files in the "cfc" directory for the SAM version. In the SAM rewrite, I have added a "search" component, an "objectFactory" component, and a "dataAccess" component. Both versions have a "user" object, a "cart" object, and a "product" object, and the SAM version has a "catalog" and a 'baseObject" object but the original version has a "_base" and a "category" object. You may be asking yourself why, if SAM makes things easier, there are more CFCs?

The object factory object was added in order to simplify the retrieval of objects throughout the application. A single CFC in the application scope now gives all of the code in the application access to whatever object they require. Different objects are handled differently by the factory - for example, some are singletons whereas others are created on the fly. I already had a copy of an object Factory CFC since I use them a lot, so I copied it into the CFC folder and modified it for the Pet Market objects. The data access component houses methods for storing/retrieving data that is not specific to any one object in my business domain (you could think of it as global data) - for the Pet Market it only needs to store two simple queries (one for states and one for shipping methods). Again, I already had a data access template file that I copied and customized. The search object is yet another CFC that I already had an API built for - along with its tag I can easily add consistent search functionality, navigation, and results display into any application.

The "baseObject" is another CFC I had already written: I use some variation of this object in nearly every application that I build. The original application "_base" object really didn't do much at all - it contained one method used by the application, which simply looped over the "this" scope in order to compile and return a structure of all the properties for any object that inherits from it. In SAM, data is kept as private as possible within objects (or tags or anything else, for that matter), so no data is stored in the "this" scope. All domain objects extend my "baseObject", which has generic property accessors for getting and setting. My baseObject also includes functionality for easily defining what properties may be set or retrieved, for defining validation rules on properties, for validating property values, and for retrieving validation error information.

Another major difference between the two CFC code bases is that the original application had a "category" object whereas the SAM code has a "catalog" object. In "object think" terms, a catalog is made up of products and the products fall into categories (which are really just metadata), and a user owns a shopping cart and a search object (searches are user specific). In the original version there is no clear ownership of data or functionality, but these are clearly defined in the rewrite. The original application had some CFC methods that output directly to the screen, but this is not allowed when following the Sensible Assembly Methodology. The impact of writing to the screen from tag APIs rather than objects is clear when comparing the number of tags and browsable files in the two applications.

More Stories By Simon Horwith

Simon Horwith is the CIO at AboutWeb, LLC, a Washington, DC based company specializing in staff augmentation, consulting, and training. Simon is a Macromedia Certified Master Instructor and is a member of Team Macromedia. He has been using ColdFusion since version 1.5 and specializes in ColdFusion application architecture, including architecting applications that integrate with Java, Flash, Flex, and a myriad of other technologies. In addition to presenting at CFUGs and conferences around the world, he has also been a contributing author of several books and technical papers.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
SYS-CON Belgium News Desk 02/01/06 01:29:21 PM EST

I've been fairly outspoken for quite some time now about the fact that I don't subscribe to any one framework. I've also spent many years refining what's proven to be the best methodology possible for developing ColdFusion applications. I recently promised my boss that I would learn and evaluate several of the popular ColdFusion frameworks.