|
#2
live412006-08-21 10:47
[英文原文]Comparing and contrasting Mach-II and Fusebox 4.1 frameworks for Co
The ColdFusion MX development community is maturing. Most CF developers have moved past spaghetti code and the mixing of business logic with presentation code. But it can be difficult and wasteful to "re-invent the wheel" for every application you write. Frameworks can help promote good development practices, standards, and a sound foundation for creating an application. In the ColdFusion world, two frameworks have risen to the top of the heap: Fusebox and Mach-II. In this article I'd like to talk about each of these free frameworks, compare them, and offer suggestions on how to decide which (if either) you may want to adopt. Fusebox 4.1 When users call a Fusebox application, they pass in an "action" value, typically called a "fuseaction". Based on the specified fuseaction, the application executes code to fulfill that request. Fusebox developers write XML to tell the framework how to respond to different fuseactions. They also use XML to define application-level settings such as character encoding, error handling templates, and "circuit" aliases. Circuits are sub-elements of a Fusebox application that allow for smaller and more cohesive groups of fuseaction handlers. Developers leverage a set of "core files" that implement the Fusebox framework. These core files handle all of the low-level plumbing, setting up memory structures, and reading and parsing the XML files. Fusebox is a procedural framework. That means that the core files themselves are written in a procedural fashion. On the same note, the fuseaction handlers that Fusebox uses occur in a procedural way. Execution of a fuseaction happens in a "top to bottom" manner, as defined in the XML written by the developers. For example, the XML may specify that to fulfill a specific fuseaction, two ColdFusion templates must be included and executed in a specified order. The plus side of this predetermined behavior is that the core files "compile" the actions defined in the XML into a single file that handles each fuseaction. This results in very fast performance, because once the "compilation" step happens, all future requests skip that step and execute the "compiled" fuseaction file directly. The Fusebox framework allows for the use of plugins, which are code files that can be set to run at specific points during the execution of a request. Plugins are a way to expand the capabilities of the Fusebox framework without modifying the core files. They are useful for things like error handling, layout nesting, or security logic. Fusebox 4.1 also offers new support for ColdFusion Components (CFCs). CFCs are object-like constructs that offer many of the benefits of object-oriented programming to CF developers. It is now possible to instantiate and invoke methods on CFCs from XML files. However, while CFCs can be used within a Fusebox application in small ways or as an entirely object-oriented model layer, they are not required. It is fully possible to write a Fusebox application that does not use CFCs at all.
The entire Mach-II framework code is implemented in CFCs. Mach-II also requires developers to write CFCs to handle the business logic within an application. As such, Mach-II is an object-oriented ColdFusion framework and effective development with Mach-II requires that one have a firm grasp of object-oriented programming principles. This includes concepts like polymorphism and design patterns. Users pass an "event" value into a Mach-II application, and the framework responds based on the specific event requested. This is similar to Fusebox's "fuseaction". Also similar to Fusebox, Mach-II developers write XML to determine how a given event is handled. However, unlike Fusebox, the flow of a Mach-II request is not procedural. Developers can use CFCs or XML to announce additional events, or dynamically specify which event handlers should respond to an event. It is for this reason that Mach-II is an "implicit invocation" framework. In fact, the "II" in the name Mach-II means "implicit invocation". Implicit invocation provides additional flexibility in a Mach-II application, but it also results in a performance penalty. Fusebox can "compile" a fuseaction into a single file. Such a step is not possible in Mach-II due to its more dynamic nature. Virtually all business logic in a Mach-II application is handled within CFCs. Developers write listener components which extend the Mach-II framework CFCs. Event handlers notify the listeners and the listeners in turn call on the CFCs that make up the object model of the application. In this sense, the listeners act as a communication bridge between the framework and the underlying business objects. This forces a degree of encapsulation upon the business objects, as they need to have little or no knowledge of the framework. Such encapsulation is possible in Fusebox, but it is not enforced by the framework. Like Fusebox, Mach-II also allows for plugins that can execute at specific points during the handling of a request. In keeping with its object-oriented nature, Mach-II plugins are implemented with CFCs. [此贴子已经被作者于2006-8-21 10:50:42编辑过] |
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 框架不强迫这样做。