Mozier's weblog

<cfweblog author="Mozier" attention="ColdFusion,BlueDragon,CFML,Model-Glue,Mach-ii,etc" />
  订阅 订阅  :: 管理

ColdFusionMX 下 Mach-II 和 Fusebox 的比较

Posted on 2006-04-05 11:04  Mozier  阅读(1519)  评论(0编辑  收藏  举报

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 框架不强迫这样做。