Mach II or ColdSpring? Understanding the Differences Between ColdFusion Frameworks

So, you have been thinking about getting into frameworks and using Mach II but you have also been hearing a lot about ColdSpring. Which one should you use?

I am paraphrasing here, but this is a type of question I have seen from time to time posed on lists, blogs and elsewhere. In part this has to do with a generic use of the term "framework" to apply to a lot of different projects that solve entirely different problems. You could, for instance, build an application that uses Mach II, Transfer and ColdSpring, thereby using three (or more) frameworks in a single application and this would be totally appropriate. Why? Well because Mach II is concerned, in very general terms, with your overall architectual pattern, Transfer with your persistence mechanism and ColdSpring with managing dependencies within your model. Confused? Well, here is a guide to the most commonly referred to types of frameworks, the problems they attempt to solve and the well-known ColdFusion frameworks associated with that type.Writer's Note: First, if you find factual/conceptual errors or inconsistencies, please see my note at the end of this post. Second, while all kinds of frameworks in ColdFusion can be a hot button issue, this post was written in an attempt to present the topic in a more general and objective manner primarily for beginners. There are no digs in here, and if you find one, its because you are looking for them (and your determination is coloring your reading). So I welcome constructive criticism but, please, no flames.

Model-View-Controller (MVC)
This is the largest category of ColdFusion frameworks and includes many projects with a wide-range of features but that, at their core, solve the same architectural problem. That problem would be how to protect your user interface (UI) from having to know about changes to your model, which basically represents your data, and vice-versa.

MVC does not have to be object-oriented (OO). In fact, the first MVC framework for ColdFusion, Fusebox was decidedly not OO in its early years (nowadays it can be used procedurally or with objects). Mach II was spun off of Fusebox and, in its first early beta phases, was originally called Fusebox MX. Mach II took a more object-oriented approach towards MVC with the advent of CFCs in ColdFusion MX. Both of these frameworks have been around for quite some time and are widely used throughout the ColdFusion community.

Model-Glue, another more recent ColdFusion MVC framework, has gained a strong following lately in part by simplifying how various events were called via the configuration XML (and theoretically being easier on someone new to object-oriented concepts). Although not yet in a stable release, Model-Glue 2.0 (called Unity) has diverged further from the Mach II mold by including a number of features like scaffolding and object-relational mapping (discussed later) normally associated with the Ruby on Rails MVC framework for the Ruby programming language.

While these frameworks make up the "big three" of ColdFusion (as some refer to them), they are by no means the only ones, though most of the others are relatively new. Some of the others include the ColdBox Framework, ColdFusion on Wheels and CFRails, to name only a few of the more well known.

Inversion of Control (IoC) or Dependency Injection
The two terms used to describe the next set of frameworks seem to be used interchangeably. Basically IoC is a means of simplifying object dependencies (in this case obviously we mean ColdFusion components), and is therefore specifically related to object-oriented programming.

In a typical application, object dependencies are handled through a series of hard-coded calls to the dependent objects within a component, perhaps in the constuctor (init()) method (i.e. a series of CreateObject() calls in CFML). While this is functional, it can become difficult to maintain within large models that have a lot of dependencies and would require a large amount of recoding for something as simple as a component moving within the model's folder structure.

IoC solves this problem by "injecting" the dependencies into the objects when they are created, thereby relieving your object/component from having to know the specifics of where the dependency is coming from or how it is created. Most IoC frameworks can also handle circular (or cyclic) dependencies, whereby two objects are dependent on each other.

The standard for doing IoC in ColdFusion is ColdSpring, which is based in-part on Java's Spring framework and also includes an aspect-oriented programming (AOP) portion which we will discuss next. LightWire is a relatively new addition to IoC in ColdFusion, though it is still in its early stages of development.

Aspect-Oriented Programming (AOP)
Potentially the most difficult concept for beginners to understand, AOP deals with "cross-cutting concerns" (i.e. aspects) within your application. These are things like security or logging that apply to large portions of your application and are not really "objects". In fact, AOP as a concept does not necessarily apply specifically object-oriented development, though I have not personally seen it done any other way.

AOP solves the problem of integrating these cross cutting concerns by creating "join points" (referred to as pointcuts) and "advice." The join point or pointcut is the place within a program where the advice will be applied. For example, we might want to set our logging to occur before, after or around certain method calls. The advice would be what we want to happen at this join point (i.e. a method call or sequence of method calls). In our logging application, for example, the advice would be the actual implementation of the logging code.

Currently, the only framework (that I am aware of) to implement AOP for ColdFusion is ColdSpring.

Object Relational Mapping (ORM)
Many people associate object-relational mapping with CRUD (i.e. your standard create, read, update and delete code for any item in your model). While ORM does handle CRUD, there are many solutions to CRUD that are not ORM (for example, in ColdFusion, DataMgr solves CRUD in manner that is more procedural in nature). The difference is that ORM deals with a specific problem, and that is when your application's model deals in objects, but your persistence method (i.e your database) is relational. While the average person sees ORM as a way not to write queries anymore, the problem is far more complex than that (a code generator for example can solve the problem of writing queries but is not ORM).

A standard ORM solution contains a means of "mapping" object data to relational data. This means, in large part, that relationships like your "has a", "has many" or "is a" are converted to "flat" relationships using keys. Obviously your ORM also handles persisting object properties, like the "firstName" in my user object, in its proper table location in my database. While the basic problem may sound simple, ORMs have to deal with a multitude of complexities such as an single object that spans multiple relational tables or deep, nested relationships in addition to accomodating the SQL language differences between the various supported RDBMS.

While Hibernate has become a de facto standard it seems in the Java world, ColdFusion has several well known ORM projects. One of the first ORM projects in ColdFusion was Transfer, which based upon my limited experience, takes a more Hibernate-ish approach to ORM in which a Transfer "business object" is similar in many respects to Hibernate's persistance of POJOs (i.e. Plain Old Java Objects).

Another widely used and well-known ORM for ColdFusion is Reactor. Reactor's approach to ORM is quite different than Transfer, bearing more similarity to the "Active Record" pattern popularized by Ruby on Rails. Reactor also includes a full-blown object-oriented query language that theoretically eliminates the need for any portion of your model to be aware of which RDBMS it uses.

Another widely used ORM in ColdFusion is ObjectBreeze, which differentiates itself from the above two in that it doesn't require any configuration (like an XML file), but creates objects via its API at runtime.

In addition, some of the MVC frameworks listed in the above section contain some level of ORM. Model-Glue, for example, includes Transfer and Reactor integration aspects. Other "Rails-like" frameworks such as ColdFusion on Wheels and CFRails typically include some level of ORM.

Conclusion
Obviously these are not the only types of frameworks that exist either in the programming world in general or in ColdFusion specifically. However, when you hear people make the generic "framework" reference, they are usually referring to one of these four types. I think that, having covered the different types of problems they solve can help to alleviate the confusion this often causes those of us just entering the relatively new world of frameworks in ColdFusion. Now, you too will be confused when you hear someone wondering if they should use Mach II or ColdSpring.

One important note: I am by no means an expert on all of these topics or frameworks, so, if you find a concept that was wrongly explained, a term that was misused or an incorrect description of the features, requirements or approach of the frameworks discussed, please put this in the comments and I will try to take this into account and make the necessary corrections. Thanks to Wikipedia for all the reference material :)

GREAT introduction - very cool. Best I've seen.

Well done!

Great stuff! Now I have a link to give to people asking about ColdFusion frameworks :)

One of the best blog posts I have ever read. Clear, concise, and full of great information for newcomers to the frameworks.

Nice summary of the various ways of doing things, also doubles as a 'current state of the art' piece I can point people at, cheers.

Very good stuff Brian. This could almost be a living document. Thanks for clearing up some of the conceptual dust that was lingering in my head.

Excellent post! Candidate for "blog post of the year 2007" when next year's CFeMmys come around!

Good overview. I wouldn't say that Fusebox is an MVC framework but rather a framework that you can develop in an MVC style. I'd define an MVC framework to be one that all but *requires* you to work in that structure, whereas Fusebox really doesn't care if you're doing a bucket of bolts or something more sophisticated. Just a little nit-pick.

This was a fantastic post. As a beginner myself I have been exploring my framework options for some time. I do have a question though. If I'm going to be developing almost entirely in a shared host environment will I have a problem using any of these frameworks?

@Damien, good point. And while we're nit-picking, although Mach II and Model-Glue strongly encourage MVC, it's still very easy to blend the controller and the model (and lots of people do write "fat" controllers - which can lead to all sorts of problems down the line).

Regarding using a framework on a shared host, yes it can sometimes be a problem. I won't name names here, but I had trouble using Mach II on a certain large ColdFusion hosting company server. I developed a site using Mach II and my client put it on a shared server. Another site on the server had /machii mapped to their installation with a server-wide mapping. I had to rename every instance of /machii to something else in my client's instance of the Mach II code, thereby causing a huge headache for me if I ever want to upgrade their version of Mach II. Maybe in retrospect there was something else I could have done, but this was the quickest solution for me. So yeah, there was a solution but it wasn't a pretty one.

The good news for Andrew (and others) is that ColdFusion 8 now eliminates the problem he had with Mach-II. Unfortunately it won't save him the headache for upgrading that particular client to a new version of Mach-II, however, it does mean he won't ever have to go through that again, since CF8 allows him to map the MachII directory within his application. :) I realize I'm commenting rather late, this being nearly a year since you'd written this article. :) Though I thought I would throw out a little bit of info about my own framework. While certainly not as popular as these others, the onTap framework is similar to Damien McKenna's description of FuseBox, providing a good controller but still being agnostic to the use of OO, allowing you to write your applications as either OO or procedural. (Though I realize as Sean pointed out, a framework can't really prevent you from blending the model and view, it can only encourage or discourage, where Fusebox and onTap don't really do much of either. Though I do use OO for all my own model code.) The onTap framework in comparison however goes a bit further than creating integration to 3rd party ORM tools like the Transfer/Reactor integration in Model-Glue. The core framework actually includes a complete ORM of its own, which last I checked included most if not all of the features included in Ractor (though my information on Reactor may be somewhat out of date now). I actually wasn't aware -- I had already created most of the ORM features before having heard of Reactor and it was a long while before I even looked into Reactor. The ORM features which I've always referred to as a "SQL Abstraction Layer" require no XML configuration, determining database relationships at run-time, with the ability to specify explicit join conditions when the framework is unable to use the default join on a foreign key that marries two tables. Most of the time however, if you've created foreign key relationships, it's not necessary to specify the columns, only the table being joined. What I had created and called a "DAO" at the time based on these features turns out to be an implementation of the ActiveRecord design pattern (which I hadn't heard about, hence why I didn't call it that). Like the other ORM tools it can be seen as a way to not need to write SQL Queries, since you won't be writing them as long as you're using the ORM tools. For me it started as a desire to have platform-independent applications that would run on any database and not writing SQL Queries was a value-neutral side-effect, although it's grown significantly from that original vision to now provide a number of features which I don't believe any of the others currently offer, such as "and/or" keyword filtering (useful for "advanced search" type features), and DDL for executing create, alter and drop statements for altering the structure of the database, which I use for creating installers for my applications. One other thing I'll mention is that although I'm not an expert on Aspect-Oriented Programming (AOP), from your description it seems the onTap framework would fit the criteria for that as well. One example of this is that the Members onTap plugin which is designed to create flexible application security creates "advice" at a "join point" in the framework's core controller, allowing it to both perform logging (as in your example) and forward the user to the login if they lack the appropriate permissions for the current request. It does this by placing files in specific directories, allowing the other applications in the framework to take advantage of the security and logging features, while the core framework itself is totally unaware even of the presence of the security framework. I'd be willing to bet if you get a chance to look at it, that it will qualify as the first non-OO implementation of AOP you'll ever see. Anyway, great article by the way. :) Thanks for taking the time to write it.

Very interesting article indeed. Looking forward to more of your post!

I am leading a development team from a businss solutions architect perspective and am not a programmer although I have good understanding of automating processes through sw applications. Our call is for Flex/Flash and also possibly Flash/Quictime streaming with coldfusion on XServe (OSX) as server technology. What would you recommend as starting point for an solution that is not an social netowrking platform, but need to integrate to other opensocial networks to create market. The core of the solution will be online applications such as market research tools, mail list management on a SAAS or ApplicationAAS basis. Some applications relates to "project management" and we need to also provide groups with the ability to create and online space and communication to their users. We anticipate high traffic and rich media will be limited to the core essentials and linked to in other social networking and similar platforms. CMS is an issue during the early stages and we looked at farcry for a quick start