再來是MVVM,MVVM的架構壹樣是M, V分離,但中間是以VM (ViewModel)來串接,這個ViewModel比較像是View的壹個代理程式,它負責直接對Model做溝通,而View可以透過壹些機制(ex: Events, Two-way Databindings, ...)來和ViewModel溝通以取得資料或將資料拋給Model做存取等工作,ViewModel也可以作為和外部系統的代理程式,例如Web Service或是REST Service或是Enterprise Services等等,不過它和MVC不同的地方,就是ViewModel和View的黏合度比較高,因為View必須要透過ViewModel才可以取得Model,而ViewModel又必須要處理來自View的通知訊息,所以雖然職責壹樣分明,但是卻不像MVC那樣可以擴展到整個系統元件都能用。如果MVVM要和MVP比較的話,MVVM會比MVP更靈活壹點。
接著是MVP,MVP壹樣也是職責分明,且Model與View分離的架構,但是這個P (Presenter)和ViewModel就很類似,不過就如同Presenter (主持人)這個字所代表的意義,所有主控View呈現的工作,都是由Presenter來做,而View本身只是Presenter所要使用的舞臺而已,所以View原則上會相依於Presenter,但是為了要做到關註點分離(SoC原則),所以在View和Presenter間都會加入壹個介面(ex: IView),然後以IoC的方式將View註射到Presenter中,而Presenter就使用介面所定義的方法去操控,而View就透過介面所定義的方法去呈現介面即可。但也因為受限於介面,所以Presenter只能依介面定義的動作去回應與處理,而不能再做更多的延伸功能,除非更改View的介面
由上面各個架構的討論,我們可以得到以下的結果:
MVC 架構適合於大型系統,它可以分層且可以在實體層面切割為不同的機器或服務,只要彼此間具有適當的通訊協定即可。
MVVM 架構適合像XAML 這種與程式碼無關(code ignorance) 的使用者介面設計,只要View 中下特定的指令與ViewModel 串接,就可以享有ViewModel 溝通的功能,而ViewModel 只需做壹些特別的介面實作,即可平順的和View 溝通。
MVP 架構適合集中由程式碼決定View 動作的應用程式,而View 只需要實作特定的介面即可,不需要太復雜的工作,但Presenter 則可能會受限於View 介面的動作,而無法做更進壹步對View 的控制。