Ruby on Rails也是一個MVC框架

中關(guān)村村草

Ruby on Rails也是一個MVC框架

回想1979年，Trygve Reenskaug提出了一種開發(fā)交互式應用的全新架構(gòu)。在他的設(shè)計方案中，應用程序被分為三類組件：模型、視圖，以及控制器。

    模型（model）負責維持應用程序的狀態(tài)。模型攜帶數(shù)據(jù)，但又不止是數(shù)據(jù)，它還負責執(zhí)行施加于這些數(shù)據(jù)之上的業(yè)務(wù)過則。

    視圖（view）負責生成用戶界面——通常會根據(jù)模型中的數(shù)據(jù)來生成。

    控制器（controller）負責協(xié)調(diào)整個應用程序的運轉(zhuǎn)。接收外界的事件，與模型交互，并將視圖展示給用戶。

    這個三位一體的組合——模型、視圖和控制器——構(gòu)成了一個架構(gòu)模式，那就是著名的MVC。

    Ruby on Rails也是一個MVC框架。Rails強迫你將應用程序按照模型、視圖和控制器進行劃分，并遵循這一結(jié)構(gòu)分別開發(fā)各部分的功能。當程序運行時，Rails會把各個部分組裝在一起。Rails的有趣之處在于：“組裝”的過程默認地按照人們常用的命名慣例來進行，因此，一般情況下你不需要編寫任何外部的元數(shù)據(jù)配置信息。這正是Rails一以貫之的“慣例重于配置”觀念的體現(xiàn)。

    在一個Rails應用程序中，進入的請求首先被發(fā)送給一個路由組件，該組件判斷應該將請求發(fā)送到應用程序的什么部分、如何解析這一請求。這一階段將找出控制器代碼中的某個特定方法，要求它來處理請求（用Rails的行話，這個方法叫做“action”）。action可以查閱請求中攜帶的數(shù)據(jù)，可以與模型交互，也可以調(diào)用別的action。最后，action會為視圖準備充分的信息，視圖則將所需的信息展現(xiàn)給用戶。

    下圖展示了Rails處理一個請求的全過程。在這個例子中，我們假設(shè)應用程序已經(jīng)向用戶展現(xiàn)了一個“產(chǎn)品分類列表”頁面，用戶則點擊了某個產(chǎn)品旁邊的Add To Cart（“放進購物車”）按鈕。這個按鈕鏈接到我們的應用程序，URL是http://my.url/store/add_to_cart/123，其中的“123”是所選商品的系統(tǒng)內(nèi)部ID號。




路由組件收到來自外部的請求之后，立即將其拆成小塊。簡單來說，它把路徑的第1部分（“store”）看做控制器的名稱，第2部分（“add_to_cart”）看做action的名稱，最后一部分（“123”）則按照慣例被放入一個名為“id”的內(nèi)部參數(shù)。進行這樣的分析之后，路由組件就知道：應該調(diào)用StoreController這個控制器類中的add_to_cart()方法。

    add_to_cart方法會處理用戶的請求：找到當前用戶的購物車（這也是由模型慣例的一個對象），請求模型找到編號為123的商品信息，然后告訴購物車將該商品加入其中（請注意模型是如何跟蹤所有業(yè)務(wù)數(shù)據(jù)的：控制器只是告訴它做什么，而模型自己知道該怎么做）。

    現(xiàn)在，購物車中已經(jīng)放入用戶選擇的商品，我們需要將這一事實展現(xiàn)給用戶看�？刂破鲿�安排視圖訪問模型中的購物車對象，并調(diào)用視圖代碼使之呈現(xiàn)在用戶眼前——在Rails中，這一調(diào)用通常都是隱藏在幕后進行的。對于特定的action，Rails將根據(jù)命名慣例自動為其查找一個特定的視圖。

    這就是一個MVC web應用的全部家當了。只要遵循一定的命名慣例，并且合理劃分功能，你會發(fā)現(xiàn)編寫代碼邊的輕松愉快，你的應用程序會更具擴展性、可維護性。

    如果MVC僅僅是“以某種方式劃分代碼”的話，你可能會想，那還要Ruby on Rails這樣的框架干什么？答案很簡單：Rails幫你搞定了所有低級的基礎(chǔ)代碼——所有那些需要耗費你大把時間去處理的繁瑣細節(jié)。它讓你能夠?qū)Ｗ⒂趹�用程序的核心功能�?br />

轉(zhuǎn)：Ruby on Rails 學習網(wǎng)

2gua

RoR的MVC，是其標志性特性。