不想去成爲一個偉大的程序員,只想成爲一個具有良好習慣的優秀程序員。
1.什麼是MVC、MVP、 MVVM架構模式
MVC是一種架構模式，MVP與MVVM是MVC的一種變形，這兩種架構模式都將View與Model完全解耦，前者將太多的Model操作放入到Controler中後者則是將Model與Control合併，結構模式的選擇只有合適與不合適沒有好壞之分。(應該根據實際場景選擇使用的架構模式，目前自己不具備選擇適當架構模式的能力)
MVC：
MVC－－－－－Model－View-Controller
MVVM –>M：Model 模型
V: View 視圖
C: Controller 控制器
Model層。也叫模型層，主要負責和數據交互的任務。模型層主要功能有定義數據結構。從數據庫讀、取數據，數據格式驗證，讀數據進行加工處理。
Model層類似與三層架構中的DAL 層。主要與數據庫進行交互。而且進行簡單的數據處理。
View層，即視圖層，負責全部界面層的任務。事實上就是寫入數據和顯示數據。主要功能有獲得數據，顯示數據。決定界面技術（HTML，XML，Flash等）。界面排版；向Controller返回數據，決定數據傳送方式，數據驗證。
View層類似於三層中的UI層，主要是和用戶進行數據交互的。
Controller層。集控制層。接受用戶輸入的數據。調用模型和視圖完畢用戶的需求。當用戶單擊超鏈接或者發送HTML表單時。控制器事實上不做不論什麼的處理和輸出，它僅僅是依據實際情況決定調用哪個模型或者視圖去處理這個請求，然後決定使用哪個視圖來顯示返回的處理結果。
經典MVC模式中對於Model和Controller的定義則較爲模糊，以致在項目實踐中對它們的職責產生了很多不同的理解。其中比較主流的有下面兩種。
1、閉環黨
比較傳統，問題是Model和Controller職責不清，在實操時容易走形
2、開放派
MVP的前身，問題是Controller職責太重，優點是View和Model沒有了直接的關聯
MVP：
如果我們希望View和Model脫離關聯的話，那麼很容易就會使得所有的職能都落到Controller頭上，就如同上圖所示。這樣，Controller也就變成了Presenter，MVC也正式演化爲MVP。所有的數據都由Presenter來驅動，所有的業務邏輯也由Presenter來實現。
MVP模式常見於Android，是谷歌官方推薦的App設計模式。從我找到的這張圖上，可以非常明顯地看出三者之間的關係。
Model只是一個數據通道，退化成了Repository。如果將Model擴而大之，那麼就會變成下面這張圖描述的場景：
Model搖身一變，成了一個數據交換中心。
MVP模式的優點是實現了View和Model的解耦，缺點是Presenter職責太重。
MVVM：
MVVM模式現在非常流行，下面這張圖描述了MVVM模式各部分的關係和職能：
MVVM模式同樣實現了View和Model的解耦。不過和MVP模式不同的是，MVVM是從數據驅動的角度出發來解決這個問題的。ViewModel和View實現雙向數據綁定，ViewModel的數據變化自動地反應到View上。這樣，ViewModel就代表了View，成了一個Agent。ViewModel也承擔一點業務邏輯，但非常有限（也有把大量業務邏輯放在ViewModel裏面的做法，這個就和MVP沒什麼本質區別了）。所以，業務邏輯的職能就只能由Model來扛了。事實上，MVVM模式本質上是MVC模式去掉了Controller或者說是Model合併了Controller。
MVVM模式的優點是雙向數據綁定帶來的便利，Model完全不需要關心View。以數據爲核心的視角非常新穎，並且在處理業務邏輯上也更加直觀。缺點其實和MVP一樣，只不過它是Model臃腫而已。
2.爲什麼要使用MVC設計模
第一: 一種比較常用的設計模式，能夠做到各層專注於各自的功能，易於擴展、管理等。
第二: MVC使前後臺相互分離，雙方通過控制器來進行控制，且相互之間不影響。這樣在編程的時候，前臺可以安心做前臺，後臺可以專注於功能。且修改的時候非常容易。
第三：應對需求不斷的變化，程序猿對於產品狗的敵意就來自於不斷地更改需求。於是，少改、好改就成了程序員的永恆目標。行之有效的套路其實也就是分層解耦而已。無論是Model/Controller還是Model/Presenter或者Model/ViewModel，不過是分層的角度和方法不同而已。
3.MVC設計模存在的問題
1、增加了系統結構和實現的複雜性。對於簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結構的複雜性，並可能產生過多的更新操作，降低運行效率。
2、視圖與控制器間的過於緊密的連接。視圖與控制器是相互分離，但確實聯繫緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。
3、視圖對模型數據的低效率訪問。依據模型操作接口的不同，視圖可能需要多次調用才能獲得足夠的顯示數據。對未變化數據的不必要的頻繁訪問，也將損害操作性能。
4、耦合性度比較高,目前，一般高級的界面工具或構造器不支持模式。改造這些工具以適應MVC需要和建立分離的部件的代價是很高的，從而造成MVC使用的困難。
4.MVC架構模式的改進
目前無法確認別人的改進是否有問題，後續需要研究，這個還是需要更具特定場景進行特定分析。
文章每週持續更新，原創雖短，確不容易，歡迎大家點贊關注，一起交流技術一起提升成長。