Mach-II DevGuide 系列译文: 概念与核心文件

作者:  Sean Corfield

本节解释框架的概念以及描绘如何访问核心文件.很多这类信息来自我的Mach II Concepts page.

MVC:Model-View-Controller

         第一个概念是MVC(Model-View-Controller)—在这里,表现层(View)完全从事务逻辑(Model)中分离出来,而二者之间的交互是由Mach-II自身(Controller)触发的.View是简单的以HTML描述代码为基础的.cfm文件,可以使用请求(request)域变量以及事件对象(Mach-II设置的,下面有更多信息).Model是ColdFusion组件(CFCs)的集合,后者呈现了程序的所有逻辑(来自数据库与事务规则和决定的交互).Controller 从本质上看,是Mach-II本身,而Controller的参数是由mach-ii.xml文件定义的.

Mach-II里Model和Controller之间的关系稍微有点复杂.框架引进了”listeners”的概念,它是一种用来扩展框架的CF组件,为核心Controller与核心Model之间提供粘合剂.这些listener组件可以被看成是Model的一部分或者是Controller的一部分,这要看你是如何组织你的程序的了,不过你最好保持你的程序独立于框架(这样可以使它们易于被Web Services(网络服务),Flash Remoting(远程服务)或其他框架所复用).关于设计模型的章节将详细介绍这部分知识.

间接调用体系(Implicit Invocation Architecture)

第二个概念是Mach-II的根基--间接调用体系.你可以在Mach-II的官方网站得到更多这方面的信息(对此,Ben Edwards写了很好的文章).基本的前提是事件通过事件句柄,被创建(由用户或者程序)和被触发.Mach-II知道那些活动的事件,进而处理它们,必要时调用litener,描绘view,直到各个请求被完满处理.

设计模式(Design Patterns)

一些指南会提及关于设计模式的知识(比如Session Façade, Memento, Transfer Object).这儿有一些好的参考文档:

• Sun's Core J2EE Patterns Catalog (includes Composite View, Session Façade, Transfer Object)
• Martin Fowler's Catalog of Patterns of Enterprise Application Architecture (including Model-View-Controller, Gateway)
• Portland Pattern Repository's Wiki - Pattern Index (including Memento and many others)

Mach-II核心文档

框架是Mach-II目录下的CF组件集合.这个目录可以安装在你的CF文件根目录或者是定义在ColdFusion Administrator定义的常用标签路径下(如:../CustomTags).在Macromedia,Mach-II目录是在CVS下:

          {cfmxroot}/extensions/components/MachII/
         

你的程序的index.cfm文件(在

{cfmxroot}/wwwroot/{appname}/

下)只包含了通向Mach-II目录的mach-ii.cfm核心文件,如果Mach-II装在网络根目录之外的话:

<cfinclude template="/MachII/mach-ii.cfm" />
         

在包含mach-ii.cfm文件前,你可以设置

MACHII_CONFIG_MODE

,

MACHII_CONFIG_PATH

, 需要的话,还有

MACHII_APP_KEY

.默认情况下,mach-ii.cfm文件使用了作为指向程序域(用来存放程序的框架对象实例)线索生成的请求的目录(例子里的

{appname}

).可以通过设置

index.cfm

的MACHII_APP_KEY来重写它(不推荐).

Mach-ii.cfm

默认状况下会像这样./config/mach-ii.xml

(跟

{appname}

目录有关),它被用来为程序初始化框架.这个路径可以通过index.cfm里的

MACHII_CONFIG_PATH

重写.为安全起见,推荐将你的mach-ii.xml文件放置在的文件跟目录以外的位置,这样它就不能被网络浏览器访问了.在Macromedia,我们重MACHII_CONFIG_PATH如下:

<cfset MACHII_CONFIG_PATH = expandPath("/environment/{appname}/mach-ii.xml") />

注意,

/environment

是

{cfmxroot}/config/target/

的映射,后者被我们的构造系统创建.所以实际上,CVS下的配置文件是{cfmxroot}/config/development/{appname}/mach-ii.xml,并可以为分段传送,综合或者产品部署的原因被重写,虽然这是不被推荐的(我们有更好的机制来触发特定环境变量).

注意:对于CFMX6.1,expandPath()在Unit

(Solaris and Mac OS X)系统下有效,而在Windows下不能执行映射.不过这个问题已经在CFMX7里解决了.

MACHII_CONFIG_MODE

默认设置为0(动态的)( 1.0.8 以上版本).这使得Mach-II只有在mach-ii.xml被改动的情况下动态加载框架.这有助于开发,但在index.xfm里加上这样几句一样很有用:

<cfif not request.productionMode and
         

                    structKeyExists(URL,"reloadApp")>
         

                    <cfset MACHII_CONFIG_MODE = 1 />
         

          </cfif> 
         

这允许你很容易地通过在URL上加

?reloadApp

的方式

强制执行一次.在完工的时候,你通常要把

MACHII_CONFIG_MODE

改成-1 (从不).这里有不同模式效果的总结:

经常的(1)—

u        优点:对listener的修改会立即执行.

u        缺点:慢(因为框架每次都要重新载入),会隐藏一些细微的bug(因为如果listener在变量域储存了数据,它会表现出数据在请求域的假相—在listener为请求重创建的时候).

动态的(0)—

u        优点:Listener实例数据表现精确(从一个请求持续到另一个),在mach-ii.xm配置改动时容易重新载入;

u        对Listener的修改不能自动执行(你需要修改xml文件来获得listener的修改.

从不(-1)—

u        优点:创造稳定的产品环境;

u        缺点:作任何修改都需要重启服务器.

在macromedia,我们设置

sitewideconstants.cfm

里的MACHII_CONFIG_MODE为默认的”动态的”来开发和测试环境,对成品设置为”从不”.标准的mach-ii.cfm文件在它被定义并且你没有重写index.cfm里的MACHII_CONFIG_MODE情况下使用这个默认

(

request.MachIIConfigModel

).