mvc 圖解，以及android 的mvc

實際中通常會用實用mvc開發。

人員數量和配合默契就能夠上標準mvc，或者純mvc.

本身作出對比，目的是概覽下mvc，和它要解決的問題。

mvc 的目的是隔離 model和view,因此要control .

業務邏輯多，而且但願邏輯和實際數據讀起分開，因此有分層,business, model

又但願ui從control中徹底分離，因此 靜態xml+動態語言作爲 view. view提供方法。這裏對團隊就有點高要求了。

固然若是系統已經幫你作好了mvc框架，那就更方便了。好比.net mvc 框架，由系統提供了v,c徹底分離以及通信的方案

既然分離了。那再加上接口也是當能的。就是所謂pure mvc。也就是mvp。

mvp感受沒有實際意義。mvp最大做用我的認爲是方便ui單元測試。可是ui測試的編寫實際上是難於編程自己的。因此帶來的優勢反而小於耗費。徹底不符合當前的軟件環境的設計模式。

目前感受就是若是一個界面有多個小ui模塊，若是某個ui模塊須要調用其餘模塊的方法。那麼就強耦合了。那麼就採用中心和點的模型，到這裏就是vm，

經過model來做爲中心，多個view做爲點。ui之間就能夠內聚，只須要和model聯繫。我的目前的心得而已。

並且model做爲中心，是能夠改變view的，這樣就避免了以前可能會有冗餘數據在contro中。致使數據沒有惟一源的風險。

 

mvc 目的是着重處理 界面層的模式概念。

而咱們說的分層是整個項目包括界面，邏輯，數據存儲 的劃分。

 

詳細通用mvc+分層結構圖

 

 

 

 

發展	通用系統	android系統	asp.net	說明
最初		由於android 有activity +sqliteOpenHelper 因此通常不會出現如此混亂的佈局
粗糙的mvc
實用mvc			.net  .webform
標準的mvc		簡潔非標準的方案。搞笑的google.	asp.net的mvc， 由框架提供支持， view 和control已經分離。不須要開發人員進行處理。 從理論上是標準的mvc。 1.輸入網址，解析到control. 入口是control.沒有任何問題。 2.control是徹底接觸不到view的。 這個是ms的mvc的特點。以前的webform是沒有作到的。 view也接觸不到control， 固然這個是web項目的特色。http網絡傳輸。 能夠看到ms的control，由框架提供服務， 只要return view(). 那麼view就能夠得到字典類型的數據。 能夠看出一點。 ms的control是隻處理業務邏輯的。 傾向直接把數據給view, 界面的邏輯仍是留給view本身處理。 對應於android 的項目， 就是control最好不要進行太細節化的控制view. 如初始化 方法能夠initview(map xx) 這樣前端能夠拿到字典數據。自由處理本身界面。 用戶動做能夠xxdata clickOk()。 這樣control返回數據，操做交給view.view獲得數據本身 安排本身的顯示，而不是提供接口給control來調用。	雖然標準，可是view要寫不少方法， 給control調用 大部分仍是會回到上面的模式。 進行開發。由於快速。 而對於android,要作成標準 又簡潔的的mvc， 竟然成爲了避免可能。 由於activity，又是入口， 又是做爲view的必選之路。 （不用fragment的話） 致使activity，又是control，又是view....... 因此要標準的mvc，必須加上fragment. 其實有點想不明白。 微軟的mvc，ios的mvc， 都出了這麼多年。 不少經驗了。爲何google還會這樣設計？
純mvc