您的位置：首页 > 产品设计 > UI/UE

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

2006-01-30 15:32 471 查看
作者:SeanCorfield

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

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的一部分,这要看你是如何组织你的程序的了,不过你最好保持你的程序独立于框架(这样可以使它们易于被WebServices(网络服务),FlashRemoting(远程服务)或其他框架所复用).关于设计模型的章节将详细介绍这部分知识.

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

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

Sun'sCoreJ2EEPatternsCatalog(includesCompositeView,SessionFaçade,TransferObject)

MartinFowler'sCatalogofPatternsofEnterpriseApplicationArchitecture(includingModel-View-Controller,Gateway)

PortlandPatternRepository'sWiki-PatternIndex(includingMementoandmanyothers)

Mach-II核心文档
框架是Mach-II目录下的CF组件集合.这个目录可以安装在你的CF文件根目录或者是定义在ColdFusionAdministrator定义的常用标签路径下(如:../CustomTags).在Macromedia,Mach-II目录是在CVS下:
{cfmxroot}/extensions/components/MachII/

你的程序的index.cfm文件(在
{cfmxroot}/wwwroot/{appname}/
下)只包含了通向Mach-II目录的mach-ii.cfm核心文件,如果Mach-II装在网络根目录之外的话:

<cfincludetemplate="/MachII/mach-ii.cfm"/>[/code]

在包含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如下:

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

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


注意:对于CFMX6.1,expandPath()在Unit
(SolarisandMacOSX)系统下有效,而在Windows下不能执行映射.不过这个问题已经在CFMX7里解决了.

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

<cfifnotrequest.productionModeand[/code]
structKeyExists(URL,"reloadApp")>

<cfsetMACHII_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
).
                                            

                                        

                        
                        内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 点击这里给我发消息 
                    

                    

                    

                        

                         标签： 
                                                

                        

                    


                

            


            

                
相关文章推荐

                

                
            

        

        

            

            
            

                

                    
新的分享

                    

                        
                    

                

            


            

                

                    
章节导航