ColdFusion MX 开发社区正在逐渐成熟。大多数 CF 开发人员过去写的代码都像意大利面条一样乱七八糟，而且业务逻辑和表示代码都混在一起。但是要重新编写以前编写的每一个应用程序是一件难事，而且也很浪费时间。
框架（Framework）可以推动好的开发实践和标准，并为创建应用程序提供较好的基础。在 ColdFusion 的世界，有两个框架比较突出：这两个框架分别是 Fusebox 和 Mach-II。在这篇文章中，我将谈一谈这两个免费的框架，并对其进行一个比较，然后给出一些建议，以帮助你决定采用哪个框架（或者两个框架都用）。
Fusebox 4.1
Fusebox 框架到现在已经出现有六个年头了。它是 ColdFusion 下不折不扣的第一个框架。而且也是 ColdFusion 世界最爱欢迎的框架。Fusebox 4.1 已经在2005年元月份发布，这是到目前为止该框架功能最强大的一个版本。
当用户调用 Fusebox 应用程序时，他们传入一个“action”值，这个“action”一般叫作“fuseaction”。根据用户指定的 fuseaction，应用程序会执行相应的代码来完全用户的请求。
Fusebox 开发人员编写 XML 告诉 Fusebox 框架如何响应不同的 fuseaction。他们还使用XML 来定义应用程序级的设置，比如字符集编码、错误处理模板、以及“circuit”别名等。Circuit 是 Fusebox 应用程序的一个子元素，它允许将 fuseaction 处理程序组合成更小、内部耦合更紧的组。
开发人员使用用于实现 Fusebox 框架的一组“核心文件”。这些核心文件处理所有的底层工作，设置内存结构，读取和解析 XML 文件。
Fusebox 是一个面向过程的框架。这就意味着核心文件本身是以面向过程的方式编写的。因此，Fusebox 使用的 fuseaction 处理程序也是以面向过程的方式工作的。Fuseaction 的执行采用的是“自顶向下的”方式，由开发人员编写的 XML 所定义。例如，用户编写的 XML 文件可以指定：为了执行一个特定的 fuseaction，必须包含 ColdFusion 模板，并以指定的顺序执行。
这个预先确定的行为的一个附加作用是核心文件将定义在 XML 中的 action“编译”到一个单独的文件中来处理每一个 fuseaction。这样就能够获得很高的性能，因为在“编译”步骤完成之后，以后所有的请求都会跳过这一步，而直接去执行“编译后的”fuseaction。
Fusebox 框架可以使用插件，所谓插件是指可以设置为在请求的某个执行点开始运行的代码文件。插件能够在无须修改核心文件的情况下扩展 Fusebox 框架的能力。这对于错误处理、布局嵌套以及安全逻辑之类的事情非常有用。
Fusebox 4.1 还新加入了对 ColdFusion Components (CFC，ColdFusion 组件) 的支持。CFC 是以面向对象的方式组织的，它为 CF 开发人员提供了很多面向对象编程的便利。现在开发人员已经能够从 XML 文件产生 CFC 的实例并调用 CFC 实例上的方法。然而，虽然 CFC 可以以某种方式在 Fusebox 应用程序中使用，或者使用整个地作为面向对象的模型层次，但是并不是说必须这样做。完全不使用 CFC 也可以编写出 Fusebox 的应用程序。
Mach-II
与 Fusebox 相比，Mach-II 是众多 ColdFusion 框架中相对来说比较新的一个。然而，它已经很快地成为了 CF 世界的一个非常流行的框架，尤其受到那些熟悉 Java 的程序员的欢迎。直到 ColdFusion XM 6.1 发布时，Mach-II 才刚刚只是一个想法。这是因为 CFMX 6.1 引入了对 CFC 的几个关键的修正和增强。像你所想的那样，Mach-II 严重依赖于 CFC。
整个Mach-II 框架代码是用 CFC 实现的。Mach-II 还要求开发人员编写 CFC 来处理应用程序中的业务逻辑。这样，Mach-II 就是一个面向对象的 ColdFusion 框架，因此如何想使用Mach-II 进行高效的开发，开发人员必须深刻理解面向对象之道，包括多态以及设计模式等概念。
用户传递一个“事件（event）”值给 Mach-II 应用程序，Mach-II 框架根据被请求的事件产生相应的响应。这与 Fusebox 的“fuseaction”比较相似。而且，Mach-II 开发人员也是通过编写 XML 来确定给定事件的处理方式的，这点与 Fusebox 也颇为相似。开发人员可以使用 CFC 或 XML 来宣告额外的事件，或者动态地指定哪个事件处理程序应该响应某一个事件。正是因为这一点，可以说 Mach-II 是一个“隐式调用（implicit invocation）”的框架。事实上，Mach-II 名字中的“II”就表示“implicit invocation”。
隐式调用为 Mach-II 应用程序提供了更多的灵活性，但是同时也导致了性能受损。Fusebox 可以将一个 fuseaction“编译”成一个单独的文件。这一步骤对于 Mach-II 来说是不可能做到的，因为它本质上是动态的。
Mach-II 应用程序中所有的业务逻辑都是在 CFC 中处理的。开发人员编写扩展自 Mach-II 框架 CFC 的监听组件（listener component）。事件处理程序通知监听组件，监听组件反过来调用组成应用程序对象模型的 CFC。从这个意义上说，监听组件就像框架和底层业务对象之间的一个通信桥梁。这就迫使对业务对象进行较深层次的封装，因为它们只需要知道很少或者不需要知道有关 Mach-II 框架的信息。这样的封装在 Fusebox 中也有可能实现，但是 Fusebox 框架不强迫这样做。
