I have recently begun exploring the landscape of potential, mostly object oriented, controller layers for ColdFusion. Three of the frameworks that I have been working with are a substratum framework to add OO style to Fusebox 3, Fusebox 4, and Mach-II. In bouncing between these frameworks I have noticed that there are significant differences between all of them. In fact, I have noticed that for some tasks, one framework is better than another.
Taking Fusebox 3 first. It is possible to add your own CFC invokation layer to Fusebox. This works well for medium to small-sized applications, or applications that need performance. The reason Fusebox 3 works so well, even though it is so old, is that even with the many cfincludes it performs frequently better than Fusebox 4 and Mach-II due to their use of XML. The use of XML for their control files, instead of the fbx_switch.cfm file in Fusebox, enables developers to port their applications to different languages like PHP with much less difficulty. In order to port, you just need to recode your objects, you don't have to rethink how the application works. This is only of benefit however, if you intend to move the application.
The downside to using Fusebox 3 is that it requires much greater discipline from the developer. If you are commited to OO like development, and CFCs. You will have to enforce it yourself, the framework is not going to make you avoid procedural code. In some cases procedural is the way to go, but it is up to the developer to know this.
Fusebox 4 has much improved support for CFCs and OO like programming style. It uses listeners, can implement loop logic in the control files, and also allows freedom, to a lesser degree than Fusebox 3, to the developer to decide how they want to build the application. The XML control files are only read once if you set the framework to production, and then cached which enhances performance. Fusebox 4 performs almost as well as Fusebox 3 in my experience. If you use CFCs, inheritance, binding, and design patterns, it performs slightly better than Mach-II but significantly slower than the same application, coded differently in Fusebox 3 since Fusebox 3 doesn't support CFCs in the same way. It is possible to use design patterns in Fusebox 3, but it still seems just a hair faster. Granted none of this analysis is scientific, it is just my observations over time.
Mach-II I have talked about in earlier blogs, however it is still I think the best general purpose framework. It can perform somewhat slowly due to it's use of the application variable scope for almost all variables, and it's forced “implicit-invokation.” The variable issue can be avoided however by using var frequently in your objects to indicate local variables only. The error catching employed by this framework could use some work and there should be a built in way to cache invoked components to enhance performance, but these features will hopefully find their way into Mach-II 2.0, or a later version. In the hands of a skilled developer familiar with the framework, Mach-II can be very quick and scalable, however in the hands of a novice… Well, OO novices, and people really new to ColdFusion probably shouldn't touch Mach-II, it can be really frustrating. Truthfully the best framework for beginners, and people who have been using ColdFusion for a while, and want to get better at organizing their code should really look at Fusebox 3, in no time they will be ready to graduate to Mach-II. That is my opinion, and of course there are those people who can pick up a ColdFusion book and a Mach-II book on a weekend and be ready to code professionally on Monday, but most people aren't like that.
I've been thinking about trying to create my own ColdFusion specific controller layer, but it is difficult to keep it general enough for any application. Perhaps it would be better to group applications, and develop several frameworks that would work for certain groups. Well, I'll keep at it.