The ColdFusion MX development community is maturing. Most CF
developers have moved past spaghetti code and the mixing of business logic with
presentation code. But it can be difficult and wasteful to “re-invent the
wheel” for every application you write.

Frameworks can help promote good development practices,
standards, and a sound foundation for creating an application. In the
ColdFusion world, two frameworks have risen to the top of the heap: Fusebox and
Mach-II. In this article I’d like to talk about each of these free frameworks,
compare them, and offer suggestions on how to decide which (if either) you may
want to adopt.

Fusebox 4.1

The Fusebox framework has been around for over six years now. It was
one of the very first frameworks for ColdFusion. It is also the most popular
standard framework in the ColdFusion world. Fusebox 4.1 was released in January
of 2005, and is the most powerful version of the framework yet.

When users call a Fusebox application, they pass in an
“action” value, typically called a “fuseaction”.
Based on the specified fuseaction, the application
executes code to fulfill that request.

Fusebox developers write XML to tell the framework how to respond to different fuseactions. They also use XML to define application-level
settings such as character encoding, error handling templates, and
“circuit” aliases. Circuits are sub-elements of a Fusebox application
that allow for smaller and more cohesive groups of fuseaction
handlers.

Developers leverage a set of “core files” that implement
the Fusebox framework. These core files handle all of the low-level plumbing,
setting up memory structures, and reading and parsing the XML files.

Fusebox is a procedural framework. That means that the core
files themselves are written in a procedural fashion. On the same note, the fuseaction handlers that Fusebox uses occur in a procedural
way. Execution of a fuseaction happens in a “top
to bottom” manner, as defined in the XML written by the developers. For
example, the XML may specify that to fulfill a specific fuseaction,
two ColdFusion templates must be included and executed in a specified order.

The plus side of this predetermined behavior is that the
core files “compile” the actions defined in the XML into a single
file that handles each fuseaction. This results in
very fast performance, because once the “compilation” step happens,
all future requests skip that step and execute the “compiled” fuseaction file directly.

The Fusebox framework allows for the use of plugins, which are code files that can be set to run at
specific points during the execution of a request. Plugins
are a way to expand the capabilities of the Fusebox framework without modifying
the core files. They are useful for things like error handling, layout nesting,
or security logic.

Fusebox 4.1 also offers new support for ColdFusion Components (CFCs). CFCs are object-like constructs
that offer many of the benefits of object-oriented programming to CF
developers. It is now possible to instantiate and invoke
methods on CFCs from XML files. However, while CFCs can be used within a
Fusebox application in small ways or as an entirely object-oriented model
layer, they are not required. It is fully possible to write a Fusebox
application that does not use CFCs at all.

Download a comparison chart

A chart comparing the features of Fusebox 4.1 and Mach-II is
available in the TechRepublic Download Center.

Mach-II

Compared to Fusebox, Mach-II is a relative newcomer to the list of ColdFusion
frameworks. However, it has quickly become a very popular framework in the CF
world, particularly among programmers familiar with Java. Until the release of
ColdFusion MX 6.1, Mach-II was only an idea. This is because CFMX 6.1
introduced several critical fixes and enhancements to CFCs. As you might
surmise, Mach-II relies extensively on CFCs.

The entire Mach-II framework code is implemented in CFCs.
Mach-II also requires developers to write CFCs to handle the business logic
within an application. As such, Mach-II is an object-oriented ColdFusion
framework and effective development with Mach-II requires that one have a firm
grasp of object-oriented programming principles. This includes concepts like
polymorphism and design patterns.

Users pass an “event” value into a Mach-II
application, and the framework responds based on the specific event requested.
This is similar to Fusebox’s “fuseaction”. Also similar to Fusebox, Mach-II
developers write XML to determine how a given event is handled. However, unlike
Fusebox, the flow of a Mach-II request is not procedural. Developers can use
CFCs or XML to announce additional events, or dynamically specify which event
handlers should respond to an event. It is for this reason that Mach-II is an
“implicit invocation” framework. In fact, the “II” in the
name Mach-II means “implicit invocation”.

Implicit invocation provides additional flexibility in a
Mach-II application, but it also results in a performance penalty. Fusebox can
“compile” a fuseaction into a single file.
Such a step is not possible in Mach-II due to its more dynamic nature.

Virtually all business logic in a Mach-II application is
handled within CFCs. Developers write listener components which extend the
Mach-II framework CFCs. Event handlers notify the listeners and the listeners
in turn call on the CFCs that make up the object model of the application. In
this sense, the listeners act as a communication bridge between the framework
and the underlying business objects. This forces a degree of encapsulation upon
the business objects, as they need to have little or no knowledge of the
framework. Such encapsulation is possible in Fusebox, but it is not enforced by
the framework.

Like Fusebox, Mach-II also allows for plugins
that can execute at specific points during the handling of a request. In
keeping with its object-oriented nature, Mach-II plugins
are implemented with CFCs.

Additional white paper resources

“Building
Secure Internet Applications with ColdFusion MX 6.1”

“Macromedia
ColdFusion MX Evaluator’s Guide”

“ColdFusion
MX 6.1 Performance Brief”

Which framework to use?

I have only scratched the surface of the full capabilities
of these two frameworks, but I think I have highlighted their most important
aspects. So now the question for most ColdFusion developers becomes: “so
which one should I use?”

The answer primarily depends on your development style and
knowledge of OOP. In many respects, Fusebox and Mach-II are similar. They both
have a set of core files which implement the respective frameworks. They both
use XML to define how an application responds to requests.

However, there are differences. One difference: in a Fusebox
application, your XML is broken up into multiple files, and each one represents
a “circuit”. In Mach-II, the XML is all defined in one central file.
So your preference for working with one large central file vs. smaller
individual files might affect your decision. But this is, admittedly, a fairly
minor issue.

A more major issue is what version of ColdFusion you are
using. Fusebox will run on ColdFusion 5, while Mach-II requires the use of ColdFusion
MX 6.1.

But the remaining issues are more subjective. The biggest
single difference is that Mach-II requires (or at least strongly recommends) a
firm grasp of object-oriented programming. The framework itself is OO. The
events are CFCs. The listeners are CFCs. The plugins
are CFCs. And the business model is CFCs. It is common to see Mach-II
developers involved in mail list discussions about design patterns, coupling,
and cohesion. These are OO principles that take some time to understand, and a
very long time to master.

Contrast this with Fusebox. The framework is procedural.
Your application logic can be written without a CFC in sight. A Fusebox
developer doesn’t need to know anything about inheritance or polymorphism to
build an application. However, it is also possible to write all of your Fusebox
application’s logic in CFCs. Fusebox leaves the decision to leverage CFCs and
object-oriented principles up to the developer. The downside is that if you
want to take this route with Fusebox, you must be diligent. The framework does
not enforce this type of development like Mach-II does.

Mach-II also enforces the use of the Model-View-Controller (MVC) pattern. This approach firmly
separates the Controller (the Mach-II framework) from the Model (the Listeners
and other business logic CFCs) and the View (the display templates). Fusebox,
on the other hand, leaves this decision up to the developer. It is possible
(and often recommended) to write MVC applications with Fusebox, but it is not
required.

As you can see, developers who want to build OO applications
with an MVC approach will probably prefer Mach-II. Developers who are used to
coding procedural applications will probably prefer Fusebox. Again, Fusebox
will support OO-based models with an MVC design; it just doesn’t enforce or
require it.

An interesting final note is something that I have noticed
recently. As more developers, both Fusebox and Mach-II, learn more about good
object-oriented programming techniques, the more interchangeable the two
frameworks become. When a developer has written a sound object model with CFCs,
the result is a model that is well encapsulated and has limited knowledge of
what framework is in use. With a CFC model like this, it becomes relatively
easy to plug that model into either the Fusebox or the Mach-II framework!

OOP versus procedural approach

I hope that this discussion of Fusebox and Mach-II and
piqued your interest in these powerful ColdFusion frameworks. I also hope I’ve
helped you decide which one of them might be appropriate for your development
style and skill set. If you’re comfortable with OOP, or are interested in
learning it, you might want to look at Mach-II. If you want more flexibility in
the choice to use OOP or MVC, or want a more procedural approach, Fusebox is a
good bet.