【每日积累】浅谈mvc,mvvm,mvp

复杂的软件必须有清晰合理的架构，否则无法开发和维护。

如果是一個人開發 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

优点:

1. 非常直接，容易理解
2. Controller 將 Model 和 View 分开来，具有一定程度的解耦合。

缺点

1. 三者相互依賴，一但更新了其中一者，另外兩者也必須跟著修改
2. 随着需求的增加，Controller的代码会越来越臃肿
3. 难以进行单元测试。

所有通信都是单向的。

2、MVP

MVP 模式将 Controller 改名为 Presenter，同时改变了通信方向。
和 MVC 不同的是，Model 拿到数据后，并不直接交给View进行渲染数据，而是交给 Presenter来处理，Presenter 再把数据回调交給 View，并更新界面。

1. 各部分之间的通信，都是双向的。方便进行测试

2. View 与 Model 不发生联系，都通过 Presenter 传递。

3. View 非常薄，不部署任何业务逻辑，称为“被动视图”（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。

4. 责任分工明确

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 的引用，更方便进行单元测试。

优点:

1. 目前是非常迎合开发大众的需要
2. 大幅的减少了操纵dom的代码，省去了 MVP 中Presenter的介入，Model 数据的改动也不需要callback 給 view，因为 View 会通过观察者 observe 感知数据的变化并更新页面的内容。
3. 可以搭配 (DataBinding、LiveData)android等框架使用，能更方便地处理UI的更新，生命周期的处理。
4. ViewModel 能够轻易的保存数据，且可以被多個 View 共享(MVC、MVP 也可以但不太适合场景的需要)，View 与 View 之间传输数据也更方便(只有 MVVM 可以)。
5. 编写测试时，MVP 需要 Mock 一個 View 对象才能进行对应的测试，由于 ViewModel 不需持有 View 的引用，更方便进行对应的测试。

缺点:

1. 只针对android来说：入行門檻、學習成本高，且需要搭配 DataBinding、LiveData 等框架，才能發揮最大效益。
   唯一的区别是，它采用双向绑定（data-binding）：View的变动，自动反映在 ViewModel，反之亦然。
   Vue,Angular,react 以及 Ember 都采用这种模式。

以下如有纰漏，请留言，一一查阅！