Frameworks can help promote good development practices, standards, and a sound foundation for creating an application.

In this article I list a number of these frameworks, but I will leave you to compare them, and decide which you may want to adopt.

Fusebox

An Historically Strong Framework

Fusebox is a popular framework for building ColdFusion and PHP web applications. “Fuseboxers” find that the framework releases them from much of the drudgery of writing applications and enables them to focus their efforts on creating great, customer-focused software.

Fusebox provides a small set of ‘core’ files and large amount of structure which is helpful to developers. It emphasizes separation of presentation from logic and uses a readily understandable vocabulary for modeling websites, namely circuits, fuses and switches.

http://www.fusebox.org

Mach-II

Mach II is a web-application framework developed by Hal Helms and Ben Edwards that evolved out of a desire to create a framework that specifically addressed maintenance issues using an OO style. Mach II is based on an Implicit Invocation Architecture and directly supports the MVC design pattern.

http://www.mach-ii.com

Model-Glue

Model-Glue helps you build Object-Oriented ColdFusion applications based on the Model View Controller pattern. It’s designed to be easy to use and play well with others, like Tartan.

http://www.model-glue.com

onTap

The onTap framework is an Open Source Framework for quickly developing powerful web applications using Adobe’s ColdFusion application server. The framework itself bears a marked resemblance to the recently buzzy Ruby on Rails.

http://www.fusiontap.com

TheHUB

TheHUB, like other application development frameworks, utilizes the notion of a central hub template that all requests for the application pass through. That cental hub is the point or place within the application that the processing of all code hinges upon. The code simply checks for a query string and then reads the parameters passed to handle template loading and screen rendering.

http://www.codesweeper.com

Tartan

Tartan is a command-driven service framework for ColdFusion. It was built to help produce the service layer within a larger application architecture which relies on strict separation or layering of functionality.

All access to the underlying business logic is controlled by public services which are available locally as CFCs and remotly via Flash Remoting and SOAP web services. A service can be composed of any number of commands, each of which implements a discreet operation within the application. These contain the core logic for the application. Commands can communicate with databases via DAOs, manipulate values received from the client, execute other commands and even communicate with services available on other remote servers.

At the center of Tartan are 6 Core classes : LocalServiceProxy, LocalService, Command, DAO, ValueObject and ExceptionHandler. They provide most of the functionality of the framework, and must be extended by the application developer.

http://www.tartanframework.org

ColdSpring

ColdSpring is a framework for CFCs (ColdFusion Components).

ColdSpring’s core focus is to make the configuration and dependencies of your CFCs easier to manage. ColdSpring uses the “inversion-of-control” pattern to “wire” your CFCs together. Inversion-of-control provides many advantages over traditional approaches to assembling your application’s model. Also part of ColdSpring is the first Aspect-Oriented-Programming (AOP) framework for CFCs.

http://www.coldspringframework.org

UPDATE: Since creating this blog post many years ago, two more frameworks have been released that require an honourable mention.

ColdBox

My New Framework of Choice

ColdBox is an event-driven conventions based ColdFusion Framework. It provides you with a set of reusable code and tools that you can use to increase your productivity, and it provides you with a development standard when working in a team environment. It makes use of an MVC (Model View Controller) design pattern and an extensive array of patterns for its operations such as Factories, Helpers, Workers, etc. And since it is based on CFCs it does not rely on an XML dialect.

NB. ColdBox also takes advantage of ColdSpring or Lightwire.

http://www.coldboxframework.com

Lightwire

Lightwire is a very lightweight Direct Injection (DI)/Inversion of Control (IoC) engine for directly injecting dependencies into singletons and transient business object. The framework is optimised to create transient objects as well as singletons and allows for programmatic as well as XML configuration. It is the lightweight framework for people who’d like to put more logic in their beans and less in their service layer.

http://lightwire.riaforge.org

All access to the underlying business logic is controlled by public services which are available locally as CFCs and remotely via Flash Remoting and SOAP web services. A service can be composed of any number of commands, each of which implements a discreet operation within the application. These contain the core logic for the application. Commands can communicate with databases via DAOs, manipulate values received from the client, execute other commands and even communicate with services available on other remote servers.

At the center of Tartan are 6 Core classes : LocalServiceProxy, LocalService, Command, DAO, ValueObject and ExceptionHandler. They provide most of the functionality of the framework, and must be extended by the application developer.

Overview and Explanation

The driving need behind Tartan was a production application that needed to transfer data between 5 different databases and 3 different applications. There was a complex set of DAO classes and a faade class that provided access. Each fa ade class had a single public method called “execute” that would simply take arguments and return a result.

This concept worked well, but obviously had its limitations. So Tartan was created to be able to quickly and easily add new commands to services, and new services to the system.

Tartan is described as a “command-driven service framework.” What does that mean? In this context a “service” is a set of commands that have commonality, and a “command” is a method that executes any number of other methods and returns a result. It’s that simple. A service such as “televisionViewer” could include a command such as “getListings” which would, based on locality data provided either by a config file or a method argument, check local listings and return a collection of data regarding current television listings.

To further explain the concept of “commands,” we could offer that method a second argument such as “returnType” and return the listings as an array of structures, a CF query object, or an XML file. By adding commands from granular to broad, we can incorporate them into sequences. For instance, if we wanted to offer the findMyShow command, we could have it first execute getListings, then parse the resulting data and determine if our show is on soon or not.

By doing this carefully and with some planning, we develop a very simple interface between our application and any persistant storage mechanism and/or business objects, with the ability to filter, alter, or convert our results before they’re returned to the caller. If we start with granular and move to broad commands, we maintain the flexibility and encapsulation of an OO design, but gain the convenience and natural-thinking appeal of procedural programming.