复杂的软件必须有清晰合理的架构，否则无法开发和维护。
如果是一個人開發 App，不會有人管你怎麼寫、怎麼設計，反正自己開心就好。
但是如果是一群人同時在開發一個 App，這時候，層次分明、分工明確、模組化的設計架構就相當重要了，不但看起來賞心悅目，對於程式的維護性、修改性、擴充性、還有效能都能大幅提升，從好幾個人開發一個 App，變成一個團體為了一個共同的目標在合作。
MVC（Model-View-Controller）是最常见的软件架构之一，业界有着广泛应用。它本身很容易理解，但是要讲清楚，它与衍生的 MVP 和 MVVM 架构的区别就不容易了。
1、MVC
说到设计架构,最一开始的就是MVC,MVC是Model-View-Controller的缩写,Model 处理数据，View 展示页面数据 Controller 则是两者之间的桥梁负责处理业务之间的逻辑来展示对应的数据.
View 直接与使用的用户互动，当View接受到使用者的回馈（比如要换页),则就需要Controller的参与,让Controller来操作Model拿取对应的数据返回给View，View再将数据呈现给用户查阅。
以上大致是MVC的流程，一般没有去特别设计什么架构的话大概都是MVC
优点:
- 非常直接，容易理解
- Controller 將 Model 和 View 分开来，具有一定程度的解耦合。
缺点
- 三者相互依賴，一但更新了其中一者，另外兩者也必須跟著修改
- 随着需求的增加，Controller的代码会越来越臃肿
- 难以进行单元测试。
所有通信都是单向的。
2、MVP
MVP 模式将 Controller 改名为 Presenter，同时改变了通信方向。
和 MVC 不同的是，Model 拿到数据后，并不直接交给View进行渲染数据，而是交给 Presenter来处理，Presenter 再把数据回调交給 View，并更新界面。
-
各部分之间的通信，都是双向的。方便进行测试
-
View 与 Model 不发生联系，都通过 Presenter 传递。
-
View 非常薄，不部署任何业务逻辑，称为“被动视图”（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。
-
责任分工明确
3、MVVM
不管是 MVC还是MVP，都无法避免 Presenter(Controller) 的code会越来越臃肿的问题，如果能达到一样的效果(外部行为)，
程式code当然是越好(内部行为)，MVVM应运而生了。
MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。就是将Presenter 改为 ViewModel
Model-View-ViewModel 通过观察者模式者将View 和 Model 巧妙的链接在一起，在我看来一切都是思维的精进
一旦 Model 的数据发生变化，观察者View感应到某部分的数据变动，并将数据呈现在对应的ui界面上，ViewModel 甚至不需要 View 的引用，更方便进行单元测试。
优点:
- 目前是非常迎合开发大众的需要
- 大幅的减少了操纵dom的代码，省去了 MVP 中Presenter的介入，Model 数据的改动也不需要callback 給 view，因为 View 会通过观察者 observe 感知数据的变化并更新页面的内容。
- 可以搭配 (DataBinding、LiveData)android等框架使用，能更方便地处理UI的更新，生命周期的处理。
- ViewModel 能够轻易的保存数据，且可以被多個 View 共享(MVC、MVP 也可以但不太适合场景的需要)，View 与 View 之间传输数据也更方便(只有 MVVM 可以)。
- 编写测试时，MVP 需要 Mock 一個 View 对象才能进行对应的测试，由于 ViewModel 不需持有 View 的引用，更方便进行对应的测试。
缺点:
- 只针对android来说：入行門檻、學習成本高，且需要搭配 DataBinding、LiveData 等框架，才能發揮最大效益。
唯一的区别是，它采用双向绑定（data-binding）：View的变动，自动反映在 ViewModel，反之亦然。
Vue,Angular,react 以及 Ember 都采用这种模式。
以下如有纰漏，请留言，一一查阅！