首先是MVC，顧名思義，MVC是將Model, View和Controller分離，讓彼此的職責(zé)(responsibility)能夠明確的分開，這樣不論是改M, V還是C，都可以確保另外兩層可不用做任何修改，同時這樣的分層也可以加強(qiáng)程式的可測試性(testability)，View和Model基本上是相關(guān)的，但它們并不會有直接的相依關(guān)系，而是由Controller去決定Model產(chǎn)生的資料，然后丟給View去做呈現(xiàn)，也就是說，Controller是Model和View之間的協(xié)調(diào)者(coordinator)，View和Model不能直接溝通，以確保責(zé)任的分離。而Controller可以只是一個系結(jié)Model和View的小類別，也可以是大到包含Workflow, Enterprise Services或是做為外部系統(tǒng)的Proxy Services等的邏輯系統(tǒng)，MVC各元件是可以分離的組件，也可以是分離的系統(tǒng)(當(dāng)然要設(shè)計一些機(jī)制在相互溝通)
　　再來是MVVM，MVVM的架構(gòu)一樣是M, V分離，但中間是以VM (ViewModel)來串接，這個ViewModel比較像是View的一個代理程式，它負(fù)責(zé)直接對Model做溝通，而View可以透過一些機(jī)制(ex: Events, Two-way Databindings, ...)來和ViewModel溝通以取得資料或?qū)①Y料拋給Model做存取等工作，ViewModel也可以作為和外部系統(tǒng)的代理程式，例如Web Service或是REST Service或是Enterprise Services等等，不過它和MVC不同的地方，就是ViewModel和View的黏合度比較高，因?yàn)閂iew必須要透過ViewModel才可以取得Model，而ViewModel又必須要處理來自View的通知訊息，所以雖然職責(zé)一樣分明，但是卻不像MVC那樣可以擴(kuò)展到整個系統(tǒng)元件都能用。如果MVVM要和MVP比較的話，MVVM會比MVP更靈活一點(diǎn)。
　　接著是MVP，MVP一樣也是職責(zé)分明，且Model與View分離的架構(gòu)，但是這個P (Presenter)和ViewModel就很類似，不過就如同Presenter (主持人)這個字所代表的意義，所有主控View呈現(xiàn)的工作，都是由Presenter來做，而View本身只是Presenter所要使用的舞臺而已，所以View原則上會相依于Presenter，但是為了要做到關(guān)注點(diǎn)分離(SoC原則)，所以在View和Presenter間都會加入一個介面(ex: IView)，然后以IoC的方式將View注射到Presenter中，而Presenter就使用介面所定義的方法去操控，而View就透過介面所定義的方法去呈現(xiàn)介面即可。但也因?yàn)槭芟抻诮槊妫訮resenter只能依介面定義的動作去回應(yīng)與處理，而不能再做更多的延伸功能，除非更改View的介面
　　由上面各個架構(gòu)的討論，我們可以得到以下的結(jié)果：
　　MVC 架構(gòu)適合于大型系統(tǒng)，它可以分層且可以在實(shí)體層面切割為不同的機(jī)器或服務(wù)，只要彼此間具有適當(dāng)?shù)耐ㄓ崊f(xié)定即可。
　　MVVM 架構(gòu)適合像XAML 這種與程式碼無關(guān)(code ignorance) 的使用者介面設(shè)計，只要View 中下特定的指令與ViewModel 串接，就可以享有ViewModel 溝通的功能，而ViewModel 只需做一些特別的介面實(shí)作，即可平順的和View 溝通。
　　MVP 架構(gòu)適合集中由程式碼決定View 動作的應(yīng)用程式，而View 只需要實(shí)作特定的介面即可，不需要太復(fù)雜的工作，但Presenter 則可能會受限于View 介面的動作，而無法做更進(jìn)一步對View 的控制