淺談MVC、MVP、MVVM模式

        mvc的模式已經深刻人心，想必你們都很熟悉，可是未必都能遵照mvc模式。咱們的一個mvc項目比較簡單，主要是數據庫的查詢。一個DBHelp類，封裝了數據庫的操做，而後Controller中進行中各類查詢，包含分頁查詢。也就是說，全部的邏輯所有在Controller中完成。請問這仍是mvc模式嗎？

       嚴格意義上，已經違背了mvc模式，可是從實踐層面看，彷佛沒有什麼問題，這樣作簡單好多。咱們知道mvc把一個應用程序劃分了三個層次結構。Model、View和Controller，Model表明了業務邏輯，好比說數據庫的各類查詢，Controller就是調用Model中的方法，而後把Model中的數據部分填充，最後選擇View，把Model數據給View。

        咱們的Model文件夾下存放的是自定義的ViewModel，ViewModel做爲view的數據源對象。這時候，咱們是否是能夠稱爲MVVMC模式呢？咱們去掉C，加上數據綁定，這不就是MVVM模式嗎？我以爲MVVM模式的亮點在於數據綁定，也就是View和ViewModel的綁定。有一個js叫knockout.js是一個前臺的MVVM框架。WPF，也是典型的MVVM模式。

      我以爲mvc模式，適合界面和邏輯都比較複雜的項目。好比咱們用的webform，有些人會在頁面的CodeBehind中，寫入大量的代碼，少則幾千，多則上萬。界面的邏輯與功能的邏輯的代碼完全耦合在一塊兒。維護起來的確不容易。針對如此狀況，咱們用mvc是否是能好一些?不管哪種模式，都是分層的思想，沒有人能用一個方法把全部的邏輯都包含在裏面。MVC、MVP、MVVM模式，它們旨在分離View和Model，避免過分耦合。MVP模式，分離的更完全。它經過引入IView接口，在View中實現IView接口。View中能夠直接調用P，而P中注入了IView，所以P能夠間接地調用View，P中能夠調用M，M封裝了業務邏輯。這樣View和Model完全分離。這個模式好很差？就看從哪一個角度說了。若是項目中，對測試要求很高的話，這個模式確實好。View和Model能夠單獨測試。可是這個模式實現起來有些麻煩。所以，對某些測試要求高的View和Model使用此模式應該更好一些。

     MVVM模式，能夠實現對Model的實時變化的監控。以及自動化測試能夠基於此模式。

 

MVC：從View開始，用戶在View上的任何操做，均可以調用Controller，Controller調用Model，而後更新View。

 

 

 

MVP：View和Model徹底解耦

 

MVVM：View和Model也沒有直接的關係，它和MVP有點類似。

 這三個模式本質上都反映了Model和View之間的關係。傳統的MVC和MVP都是Model變化，而後更新View，可是MVVM更進一步，它的View變化，致使ViewModel直接變化。這樣最大的優勢，就是省略了從View到ViewModel的映射。咱們能夠直接」忘記」View，只須要Model和ViewModel交互。畢竟View比較麻煩，它的UI控件，也就是Html控件的多樣化，處理起來比較複雜。