MVC
簡介
MVC全名是Model View Controller,是 模型(model)-視圖(view)-控制器(controller) 的縮寫,用一種業務邏輯、數據、界面顯示分離的方法組織代碼,將業務邏輯聚集到一個部件裏面,在改進和個性化定製界面及用戶交互的同時,不需要重新編寫業務邏輯。
在很長的一段時間MVC被用於映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。在Android中,Activity的角色寬泛的說就是Controller(實際上在MVC中很難區分Activity到底應該處於V還是C的角色,因爲activity即包含了界面也包含了一部分邏輯處理),xml佈局就是 View 層的表現,而網絡請求的數據或者數據庫表現爲 Model 層。
簡單概括就是:
項目 | 說明 |
---|---|
View(視圖層) | 用戶界面 |
Controller(控制層) | 業務邏輯 |
Model(數據層) | 數據保存 |
圖示關係
下圖表達出了三者之間的關係:
View 傳送指令到 Controller
Controller 完成業務邏輯後,要求 Model 改變狀態
Model 將新的數據發送到 View,用戶得到反饋
可以看到,在MVC模型裏,Model不依賴於View,但是View是依賴於Model,這就避免不了我們會在View裏面有業務邏輯,當複用和擴展的時候由於有業務邏輯的參與,改動變得困難,比方說我們經常在點擊事件中處理網絡訪問,將拿到的數據在更新UI,就會發現界面展示層做的東西除了自身UI外還有其他自己不應該關心的事情。我們始終的宗旨是:各司其職,互相隔離。
//View和Model耦合舉例
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
findViewById(R.id.main_btn).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
//1.接口請求數據
//2.更新UI
}
});
}
}
優缺點
優點
- 耦合度較低
視圖層和業務層分離,這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼,同樣,一個應用的業務流程或者業務規則的改變只需要改動MVC的模型層即可。因爲模型與控制器和視圖相分離,所以很容易改變應用程序的數據層和業務規則。1 - 重用度高
MVC模式允許使用各種不同樣式的視圖來訪問同一個服務器端的代碼,因爲多個視圖能共享一個模型,它包括任何WEB(HTTP)瀏覽器或者無線瀏覽器(wap),比如,用戶可以通過電腦也可通過手機來訂購某樣產品,雖然訂購的方式不一樣,但處理訂購產品的方式是一樣的。由於模型返回的數據沒有進行格式化,所以同樣的構件能被不同的界面使用。例如,很多數據可能用HTML來表示,但是也有可能用WAP來表示,而這些表示所需要的命令是改變視圖層的實現方式,而控制層和模型層無需做任何改變。由於已經將數據和業務規則從表示層分開,所以可以最大化的重用代碼了。模型也有狀態管理和數據持久性處理的功能,例如,基於會話的購物車和電子商務過程也能被Flash網站或者無線聯網的應用程序所重用。1 - 成本低
MVC使開發和維護用戶接口的技術含量降低。1 - 部署快
使用MVC模式使開發時間得到相當大的縮減,它使程序員(Java開發人員)集中精力於業務邏輯,界面程序員(HTML和JSP開發人員)集中精力於表現形式上。 1
缺點
- 沒有明確的定義
完全理解MVC並不是很容易。使用MVC需要精心的計劃,由於它的內部原理比較複雜,所以需要花費一些時間去思考。同時由於模型和視圖要嚴格的分離,這樣也給調試應用程序帶來了一定的困難。每個構件在使用之前都需要經過徹底的測試。1 - 增加系統結構和實現的複雜性
對於簡單的界面,嚴格遵循MVC,使模型、視圖與控制器分離,會增加結構的複雜性,並可能產生過多的更新操作,降低運行效率。難以測試,必須手動點擊,使用各種自動化的測試工具。1 - 視圖與控制器間的過於緊密的連接
視圖與控制器是相互分離,但卻是聯繫緊密的部件,視圖沒有控制器的存在,其應用是很有限的,反之亦然,這樣就妨礙了他們的獨立重用。1 - 視圖對模型數據的低效率訪問
依據模型操作接口的不同,視圖可能需要多次調用才能獲得足夠的顯示數據。對未變化數據的不必要的頻繁訪問,也將損害操作性能。1 - 一般高級的界面工具或構造器不支持模式
改造這些工具以適應MVC需要和建立分離的部件的代價是很高的,會造成MVC使用的困難。1 - 代碼難以重用。
UI是很難重用,因爲要求總是不同。所以,導致重複的代碼四處都是,維護麻煩。
應用場景
交互簡單的小型應用程序
MVP
簡介
MVP(Model View Presenter)則是對MVC的進一步改造,MVP的出現就是爲進一步分離業務邏輯和界面處理。在MVP中,M與V完全切斷聯繫,由P進行總控。當V接收到了操作,將相應的請求傳遞到P,由P進行業務處理以及與M進行交互,同時P又在恰當的時機對view進行更新(接口 / 回調方法 / 事件)。這樣V只需要暴露出接口,V與P通過接口通訊,一方面能夠將業務邏輯轉移至P,一方面通過接口使得P可以適配多個V。
圖示關係
在MVP裏,Presenter完全把Model和View進行了分離,主要的程序邏輯在 Presenter裏實現。而且,Presenter與具體的View是沒有直接關聯的,而是通過定義好的接口進行交互,從而使得在變更View時候可以保持Presenter的不變,即重用!
不僅如此,我們還可以編寫測試用的View,模擬用戶的各種操作,從而實現對Presenter的測試–而不需要使用自動化的測試工具。
我們甚至可以在Model和View都沒有完成時候,就可以通過編寫Mock Object(即實現了Model和View的接口,但沒有具體的內容的)來測試Presenter的邏輯。
在MVP裏,應用程序的邏輯主要在Presenter來實現,其中的View是很薄的一層。 因此就有人提出了Presenter First的設計模式,就是根據User Story來首先設計和開發Presenter。在這個過程中,View是很簡單的,能夠把信息顯示清楚就可以了。在後面,根據需要再隨便更改View, 而對Presenter沒有任何的影響了。
如果要實現的UI比較複雜,而且相關的顯示邏輯還跟Model有關係,就可以在View和 Presenter之間放置一個Adapter。由這個 Adapter來訪問Model和View,避免兩者之間的關聯。而同時,因爲Adapter實現了View的接口,從而可以保證與Presenter之 間接口的不變。這樣就可以保證View和Presenter之間接口的簡潔,又不失去UI的靈活性。 2
在MVP模式裏,View只應該有簡單的Set/Get的方法,用戶用戶輸入和設置界面顯示的內容,除此就不應該有更多的內容,絕不容許直接直接訪問Model–這就是與MVC很大的不同之處。
Demo
這個是簡單的例子:
MVP demo