對MVC、MVP、MVVM的理解（一） 一、MVC MVC模式再網上的爭議是最大的，一些博客中是這樣描述的 MVC模式的通信是單向的，View觸發事件或數據的提交，到了Controller進行處理邏輯之後，返回Model給View，View再從Model中取出數據，當然View中也會有相應的邏輯。個 ...
對MVC、MVP、MVVM的理解（一）
一、MVC
MVC模式再網上的爭議是最大的，一些博客中是這樣描述的
MVC模式的通信是單向的，View觸發事件或數據的提交，到了Controller進行處理邏輯之後，返回Model給View，View再從Model中取出數據，當然View中也會有相應的邏輯。個人認為這樣的描述算是比較正確，讓我們來看看ASP.NET Core MVC項目中是如何處理的，在預設模板中的錯誤界面是這樣的
它的數據來自於Model，並且在Razor界面中做了部分的邏輯處理。那麼Model是從哪裡來的呢？
在HomeController中有一個Error方法，它返回的便是一個View，這個View中帶著一個Model。由此看來在微軟定義的MVC中View確實是依賴於Model的
那麼就有人說，這個Model不是Controller返回的嗎，那View和Model並沒有直接通信呀，MVC就是為了View和Model分離開。
1.當然我不否認這種說法，但我更偏向於前者。可以看出來Controller返回的是整個Model，並不是將Model拆分開來依次解析後返回給View，所以我覺得既然Model的數據邏輯是在View界面自己處理的，那為什麼非要不承認他們之間有直接的依賴關係呢？
2.也可以理解一下第二種說法，第二種說法觀點在於V-C-M-C-V這種走向，這種說法表示View中的Model是由Controller返回的，那麼View和Model之間並沒有直接聯繫。我認為這樣的話MVC模式更偏向於MVP模式了，那麼MVP唯一的進步就是，徹底簡化了View層，將View對Model的處理邏輯全部移動到Controller（Presenter），由Presenter給View中的控制項賦值。如下圖：
模式架構是用來設計代碼的，duck不必糾結於某兩者之間具體的關係，如果能夠使你的代碼層次更加分明，清晰明瞭，那不就夠了？如果都按照前人定好的模式去做又何來創新呢？
