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.
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.
[此贴子已经被作者于2006-8-21 10:50:42编辑过]
