MVC架構的職責劃分原則

2021-10-10 06:49:27 字數 2573 閱讀 8136

mvc設計原則

模型-檢視-控制器(mvc)是一種設計框架(設計模式)。

mvc 的目標是將業務邏輯從使用者介面的考慮中分離。

這樣,開發者就可以更容易地改變每一部分而不會影響其他。

在 mvc 中:

model 代表資料和業務規則;

view 包含了使用者介面元素,例如文字,表單等;

controller 則管理模型和檢視中的通訊。

mvc 在各種程式語言中均有實現,例如 j2ee 應用開發中,

view 可能由 jsp 實現;controller 是乙個 servlet,現在一般用 struts 實現;model 則是由乙個實體 bean 來實現。

yii framework 是乙個流行的 php 框架,它借鑑了 ruby on rails 的 activerecord(ar) 概念。

資料庫中的每乙個 table 都可以用 ar 類來方便地進行增刪改查操作。

它把 ar 當做 model,並推薦放在乙個名為 models 的目錄下面。

於是,我在自動生成表對應的 ar 之後,便望文生義想當然地認為已經擁有了 model 層。

其實,ar只不過是 dao (資料訪問層),並不是 model 層。

我們的業務幾乎全放在了 controller 裡:對使用者提交上來的表單進行各種邏輯判斷,進行計算,例項化 ar 對資料進行儲存……

因為乙個 controller 中會有多個 action,每個 action 都有這樣的業務處理。

最後,我發現我的 controller **已經超過了 1000 行。

突然有一天,leader 說,我們這個系統要開放 api 給現有的舊系統呼叫,要給第三方介面。

第三方只是要給定乙個引數,本系統給出個結果值而已,這其中的業務處理它是不關心的。

壞就壞在這裡,controller 已經實現了那些業務,但它是接受表單提交的,怎樣能夠也接受 soap 的 xml 文件呢?

controller 和套套一樣,應該越薄越好。

它的職責應該只是接受使用者的輸入,然後立刻**給別的類來處理。

這樣 controller 只負責提供不同的介面,我們才能算是將業務邏輯分離出去,而分離出去的業務也很容易進行重用。

分離出來的這部分業務由誰來處理呢?答案應該是 model。

view部分比較明確,就是負責顯示。

一切與顯示介面無關的東西,都不應該出現在view裡面。

因此,view 中一般不應該出現複雜的判斷語句,以及複雜的運算過程。

可以有簡單的迴圈語句、格式化語句。比如,部落格首頁的文字列表就是一種迴圈。

對於php的web應用而言,html是view中的主要內容。

view應該從不呼叫model的寫方法。

也就是說,view只從model中讀取資料,但不改寫model。

所以我們說,view和model是老死不相往來的。

而且,view中不直接訪問get

和_get和

g​et

和_post,應該由controller傳遞給view。

此外,view一般沒有任何準備資料處理的內容,如查詢資料庫等。

這些一般是放在controller裡面,並以變數的形式傳給檢視。

也就是說,檢視裡面要用到的資料,就是乙個變數。

對於model而言,最主要就是儲存和輸出資訊。

比如,post類必然有乙個用於儲存部落格文章標題的title屬性,必然有乙個刪除的操作,這都是model的內容。

資料、行為、方法是model的主要內容。

實際工作中,model是mvc中**量最大。

model是邏輯最複雜的地方,因為應用的業務邏輯也要在這裡表示。

注意將model與controller區分開。

model是處理業務方面的邏輯,controller只是簡單的協調model和view之間的關係。

只要是與業務有關的,就該放在model裡面。

資料校驗、public常量和變數,都應該放在model層,

也就是說,有可能被重複使用的屬性或方法,都應該放在model層,一次定義,到處使用。

model不應該訪問request、session以及其他環境資料,這些應該由controller注入。

好的設計,應該是胖model,瘦controller。

對於controller,主要是響應使用者請求,決定使用什麼檢視,需要準備什麼資料用來顯示。

因此,對於request的訪問**,應該放在controller裡面,比如get

、_get、

g​et

、_post等。

controller應該僅限於獲取使用者請求資料,不應該對資料有任何操作或預處理,這應該放在 model 裡面。

對於資料的寫操作,要呼叫model類的方法完成。

對於使用者請求的響應,要呼叫檢視渲染。

此外,一般不要有html**等其他表現層的東西,這應該是屬於view的內容。

yii framework 的官方文件中有這麼一段:

簡言之,rich model is better。

文章參考:mvc的劃分原則

mvc 職能劃分 MVC架構的職責劃分原則

最近負責乙個專案,用了 但是隨著對業務邏輯理解的深入,才開始意識到問題的嚴重。我錯誤地理解了 mvc 中的 controller,想當然地根據以往的經驗,把所有的業務邏輯都放在 controller 的 action 中去實現。於是,每乙個 controller 的 都上千行,越來越臃腫。最後,我下...

MVC架構的職責劃分

模型 檢視 控制器 mvc 是一種設計框架 設計模式 mvc 的目標是將業務邏輯從使用者介面的考慮中分離。這樣,開發者就可以更容易地改變每一部分而不會影響其他。在 mvc 中,view 可能由 jsp 實現 controller 是乙個 servlet,現在一般用 struts 實現 model 則...

mvc 職能劃分 MVC的劃分原則

mvc的劃分原則 對於mvc中三者的劃分並沒有十分明晰的定義和界線,只是一種指導思想,讓你按照model,view,controller三個方面來描述你的應用,並通過這三者的的互動,使應用功能得以正常運轉。其中,view的部分比較明確,就是負責顯示。一切與顯示介面無關的東西,都不應該出現在view裡...