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.
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.
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
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.