iOS进阶-01：理解架构模式MVC、MVP、MVVM设计原理

一、MVC

       作为 iOS 程序员大家肯定很熟悉这个架构模式，这也是最常见的一种架构模式，现在我们应该从性能和成本这两个方面，来考虑到底哪种架构模式才是最适合当前公司的项目。

        MVC 由 M（model）V（view）C（controller）构成，这三者在项目中分别有不同的功能。M（model）数据模型，V（view）视图控件，C（controller）控制器。MVC 在被设计的初期，M 只单纯负责数据的存储，V 只是负责视图控件的展示，C 用于两者之间的交互传输。

        MVC 的优点在于代码的易懂性，能够较为明确的分明数据层和视图层之间的区分关系，对于新手或者刚入门的开发者不会产生较高的门槛，在后期维护和版本迭代中也能够快速入手和定位位置。

        如图所示这是最基础的 MVC 视图分类，但这其实并不是严格意义上的 MVC，因为此处的View 和 Controller 并不是严格的分割开的，这里的 Controllr 其实是 ViewController，而此处的View 是在 ViewController 上需要自定义展示用的视图控件。所以 MVC 的弊端就此出现，其 V 和 M 并不是严格通过 Controller 来控制的，而且 View 的 Controller 的严重耦合性，导致其代码的复用性很差。

        MVC 设计模式初期的概念就是 M 只做数据处理，V 只做视图展示，C 来控制数据更新和视图更新，但是由于 V（view）和 C(controller) 无法彻底分割，导致 V 和 M 之间也产生了双向联系，在很多使用中 V 和 M 不仅产生了直观的数据交互和更新，也导致很多代码的易读性产生了冗杂。所以为了解决这些问题才出现了下面的架构模式 MVP 和 MVVM。

 

二、MVP

        正如上面所说 MVP 是为了解开 Controller 与 View 之间的绑定问题，在 MVP 的设计初衷里面是将之前的 Controller 当做一个 View 来对待的，其功能就是为了单纯的做 UI 层面的展示功能，而 View 与 Model 之间的沟通与数据传递都是通过 P（Presenter，交流控制者作用就是为了数据间的传递）。

        但是这时就有人会问了，难道 MVP 不就是等价于苹果对于 MVC 的设计理念吗？其实我们并不应该这样去认为因为 MVP 并不是传统意义上的 MVC，因为P（Presenter）是独立于MVC 设计模式单独存在的一个为了解决 V 和 M 之间互相交互的一个媒介，从而减少或者可以称之为阻断 V 和 M 之间相互交流的可能性，从而使代码的业务逻辑层次更加分明。

        不过MVP也有其不好的地方，因为MVP中的P是独立与MVC 之外并用于处理V和M之间的交互和执行逻辑类，在实现P用于处理V和M之间数据交互和事件处理的功能，这就需要手动实现很多的事件和数据绑定，这就导致了其代码量的大幅度增加，对于开发周期的时效性产生拖累。

        由于MVC的设计模式本身问题原因导致其单元测是的可能性很差，由于V和C的固有绑定，以及V和M之间的相互通信从而导致单元模块的不明确，而MVP的设计初衷就是为了解决V和M之间和互相通信，使每一个功能都可以有一个单独的模块来管理从而明确了测试单元，所以MVP的可测试性很强，但是代码量会很大。

三、MVVM

        MVVM 的出现和 MVP 的出现很类似 MVVM，其核心也是将 Controller 等价看做 View，并抽出 V 和 M 之间的交互逻辑，但是 MVVM 的核心操作完全是通过事件绑定来实现的，M（model）V（view）VM（viewModel）这三者之间的交互都是通过事件信号量来执行的，其执行逻辑都被单独的放在了 VM 之中。其中最出名的莫过于 ReactiveCocoa，其核心功能就是为了实现 MVVM 这一设计模式。

        MVVM 是基于 MVP 的升级版，MVP 所拥有的特性 MVVM 依旧拥有，但是 MVP 是通过P来处理 V 和 M 的事件，绑定是 V 和 M 之间的交互，但是 MVVM 更加明确的阻隔了 V 和 M 的交互可能，直接绑定 View 和 ViewModel，在监听 model 的数据产生变化时，直接通过映射事件来实时改变 View 的效果。

        MVVM 基于 MVP 的优点，是通过使用 View 和 ViewModel 的绑定在 MVP 的基础上会减少部分代码量，但是由于事件的绑定问题和代码单元模块的抽出对于开发者 MVVM 的错误定位功能较差，由于大量使用事件绑定，其复用性很强，由于减少了 MVC 之间的相互绑定其耦合度也大大降低。

四、总结

        其实 MVC 和 MVP 以及 MVVM 三者之间都是对于项目的一种设计和优化，并不存在绝对性，因为同一个项目可以包含不同的设计模式，项目初期由于时间紧迫使用 MVC 快速产出代码和效果，但是后期维护中针对单一模块一旦出现 MVC 的耦合度过高，导致代码维护度太低时，我们就可以使用 MVP 和 MVVM 来实现功能。所以说设计模式其实是对于项目的整体优化，也是自己能力提升的体现，使用哪个并不是绝对的，作为开发者应该权衡其中的利弊来择优而用。