[转载]Fusebox or Mach-II? - 编程论坛

For more than seven years, Fusebox (www.fusebox.org), now in its fourth version, has been the dominant framework for building ColdFusion applications. During that time, Fusebox has evolved from a set of best practices into a mature framework capable of tackling very large jobs while remaining easy enough to use for everyday small tasks.

As one of the contributors to Fusebox, I've been very gratified by the tremendous response from developers who regularly e-mail me, relating stories of their success using Fusebox. Here's a sample e-mail I received recently: I'm writing to thank you for your efforts on Fusebox. I went to one of your classes in DC three years ago, and Fusebox, along with FLiP, has let me turn out one success after another. My boss started out skeptical, but he's seen the results and now Fusebox is a requirement for all new hires. Fusebox rocks!

Of course, there are a few who e-mail me to tell me how much they hate Fusebox. Here's one such e-mail: Fusebox, what exactly is it? A methodology? A framework? I think it's a cult, turning out little Fusebox disciples that spread the stupid Fusebox message. I've gone on too many consultant gigs where they required Fusebox, and I spend half my time explaining how lame Fusebox is. I was tempted to respond to my correspondent that perhaps he would have had better success if he had spent all of his time solving their problem instead of engaging in religious wars, but I simply thanked him for his post.

Over the last year, I've worked with Ben Edwards on a new framework, called Mach-II (www.mach-ii.com). Since I'm associated with both Fusebox and Mach-II, I receive e-mails asking me which one I really like. Well, I like both of them - for different reasons. In this article, let's take a look at what Web frameworks are meant to do and examine the similarities and differences between Fusebox and Mach-II.

What is a framework? The definition I find the most helpful comes from the Earth System Modeling Framework, a collaboration of universities and corporations concerned with earth science: We use the term framework to refer to a structured collection of software building blocks that can be used and customized to develop components, assemble them into an application, and run the application.

A framework provides prebuilt and pretested code that can be used as a skeleton on which to build applications. Web frameworks may be lightweight or heavyweight. Heavyweight frameworks typically apply themselves to a particular domain where they offer greater help in building domain-specific applications and require a greater degree of conformity as to the code being written. Lightweight frameworks are usually more generic (meant to deal with many different domains); they offer basic plumbing assistance and provide greater latitude in the way that developers write code.

Both Fusebox and Mach-II are lightweight frameworks. They offer help connecting the presentation tier of an application with the business logic and data persistence tiers.

Why bother using a framework? Here are a number of reasons:

Improved reliability: Working with the prebuilt components of both Fusebox and Mach-II means working with pretested components. This reduces the bugs to which one-off code is prone.
Developer productivity: Having prebuilt code assets means that a substantial percentage of the code you'll need to make your application run has already been written. And though all frameworks have a learning curve, the price to learn the framework is paid once while the benefits in terms of faster delivery of software continue to pay off.
Better, more granular security: A robust security model is not a trivial thing to implement. It just makes sense to have base security capabilities built into a framework rather than having to develop one for each new application.
Easier team development: It may be, as the old song says, that you say toe-MAY-toe and I say toe-MAH-toe, but by agreeing on a common framework, we can work on different aspects of an application without fears that our two efforts will be incompatible.
Faster delivery: Given coders with the same skills, a development team that starts off with 30% of its code written for it will have a substantial advantage when working to a tight deadline.
Reusable code assets: Code written for one specific application within a given framework context can often be reused for another application.
Less expensive development: All of the above benefits boil down to this: it costs less to build the same application with a framework than without it. In the competitive environments in which most of us work, the cost differential can be a very important factor.
Every framework, like every application, has design tradeoffs. We start off on one path - taking this road rather than that other one - and those choices have consequences. Many of the religious wars fought in the tech sector are brought about by one partisan concentrating on the strengths of his/her particular choice, ignoring the tradeoffs involved in that choice. And, of course, the disputant on the other side does the same. These great debates are usually framed in the most simplistic possible way: Which is better, A or B? But, without specifying what they mean by better, both sides argue at cross purposes.
The framework we choose should be determined by our own circumstances and needs. Fusebox and Mach-II fit the same architectural role, but approach their jobs from different perspectives and offer different benefits. Both Fusebox and Mach-II rely on an XML configuration file whose chief job is to determine what actions shall be taken in response to a specific request. Both frameworks allow developers to extend the basic framework by means of plugin points - specific times in the execution of a request where developer-provided code is run. Both frameworks allow for separation of presentation code from business logic and data persistence.

Those are their similarities. Their differences lie chiefly in the way that both frameworks solve the same problem. Mach-II takes an unabashedly object oriented approach to application development. Developers make use of the framework by using and extending prewritten classes.

Mach-II was conceived as an implementation of the Model-View-Controller (MVC) design pattern, adapted for the Web. This imposes certain restrictions on developers. Done correctly, the model part of MVC is separate from any single application. When creating the model layer, developers make a scale model of the domain in which they are interested. Model components have no presentation aspect. Instead they serve to capture business logic in the context of objects.

Let's take an example. Here is a CFC that models an Employee for the ABC company.

<cfcomponent displayname=Employee> <cfset variables.firstName = /> <cfset variables.lastName = /> <cfset variables.dateOfHire = /> <cfset variables.payStrategy = />   <cffunction name=getYearsInService access=public returntype=numeric output=false> <cfreturn DateDiff('yyyy', now(), getDateOfHire()) /> </cffunction> <cffunction name=isVested access=public returntype=boolean output=false> <cfif getYearsInService() GT 5> <cfreturn true /> </cfif> <cfreturn false /> </cffunction> <cffunction name=getPayDue access=public returntype=numeric output=false> <cfreturn getPayStrategy().getPayDue(this) /> </cffunction></cfcomponent>
Notice that there is no presentation code. There is also no data persistence code: no queries to get information from-or write information to-a database. The reason is that domain models confine themselves to modeling the business itself. They don't concern themselves with how users might view the business or with what interface will be used to interact with the model; nor are they concerned with their own persistence.

For many ColdFusion programmers, that just seems wrong. How can you get information without a database? What good is a model if users can't interact with it? From the object oriented (OO) viewpoint, though, what we have is a good example of highly cohesive encapsulation. An Employee object should only be concerned with its own, narrow sphere of interest. It's not that OO programmers aren't concerned with issues of presentation and data persistence. There will be other objects, specialized for those jobs, to handle these aspects.

This object think gives rise to many highly specialized components that are interdependent on other components to accomplish their work. At runtime, objects send messages back and forth to other objects in response to a particular request. In fact, a running OO application greatly resembles a complex conversation among many participants. The smarts of the model lie not in any one component, but in the interaction of all of the components. For an analogy, you might think of an anthill.

As someone who teaches OO to ColdFusion programmers, I can attest to how utterly foreign this type of development initially seems to programmers reared on the procedural model. But talk to these same procedural programmers by the end of the class, and an overwhelming majority, having become accustomed to this strange, new way of thinking, see the greater maintainability and reusability of individualized components. A well-constructed model can work with many different applications and we get real code reuse, not simply copy and paste repurposing of code.

Mach-II is ideal for this type of development. It provides a way to integrate individual model, data persistence, and view components into an application, while keeping the separate parts separate. If you are very comfortable working with object orientation, you'll likely find Mach-II a natural fit.

Fusebox is a procedural framework that can work with object models (just as Mach-II does) but can also be used by procedural programmers writing procedural code. Fusebox 4 also encourages the use of the MVC design pattern (adapted for the Web), but does not require developers to adopt MVC.

So, which is better? I'll give you a breakdown of what I consider to be the strengths and weaknesses of both frameworks, but first, I'd like to encourage you to find out more about both frameworks by attending the annual Fusebox conference on September 18-19 (Saturday-Sunday) in Rockville, Maryland (DC area).

This year, we'll be releasing version 4.1 of Fusebox at the conference. This newest version includes native XML support for object invocation and a new assertion mechanism, as well as other improvements. There will be talks and hands-on workshops. Whether you're an old Fusebox pro, or someone who wants to evaluate Fusebox, I highly recommend coming to the conference. For more info and registration, go to www.cfconf.org/fusebox2004.

Strengths Weaknesses
Fusebox excellent for team development
encapsulation model not as strong

mature
code reuse through copy/paste

has supporting methodology (FLiP)

relatively easy to learn

good documentation with Fusedocs

strong community support

excellent performance due to parsing cycle

Mach-II excellent encapsulation model
works better with small teams of experienced OO programmers

reuse of code rather than repurposing of code

better support for framework plug-ins
harder to learn

helps developers fully embrace the OO model
no accompanying methodology

can be used with CFCs or with Java

In short, there is no single answer to the question, Which is better? It depends on your background, on the makeup of your development environment, and on what you're trying to accomplish. With both Mach-II and Fusebox, we have a well-thought-out and implemented framework for helping us write applications better and faster. By any standards, the choice of either framework is a winning one.

See you at the Fusebox conference!