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

).