iOS设计模式mvp

专业小程序设计开发——助力新电商新零售

电话+V：159999-78052，欢迎咨询iOS设计模式mvp，[小程序设计与开发]，[小程序投流与推广]，[小程序后台搭建]，[小程序整套源码打包]，[为个体及小微企业助力]，[电商新零售模式]，[小程序运营推广及维护]

一、产品研发过程中的mvp一般是指

产品研发过程中的mvp是指Model-View-Presenter，其中Model提供数据，View负责显示，Controller/Presenter负责逻辑的处理。

Model-View-Presenter（MVP）是一种应用程序表示层的设计模式。在MVP模式中，视图层（View）和模型层（Model）被巧妙地分离开来，视图层提供一个给表示层（Presenter）调用的接口，通过该接口，表示层（Presenter）能够与依赖系统其它部分的视图元素进行交互。

一、MVP模式的介绍：

1、Model负责实现业务逻辑，保存数据，状态信息，Model仅仅向Presenter提供一组服务接口，隐藏了内部实现的细节；

2、View负责与用户交互，它接收用户的操作、输入信息，与Presenter交互获得数据，展示给用户；

3、Presenter是View和Model的中间层，它接收来自View的输入，并将其传递给Model，然后依据处理结果更新View。

二、产品研发过程中的mvp的优点：

1、模型与视图完全分离，我们可以修改视图而不影响模型，

2、可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部，

3、我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁，

4、如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。

扩展资料：

与传统的表示层相比，MVP模式下表示层的优势体现在下面三个方面：

1、View与Model完全隔离。得益于此，Model和View之间具有良好的松耦合设计，这意味着，如果Model或View中的一方发生变化，只要交互接口不变，另一方就没必要对上述变化做出改变。

2、Presenter与View的具体实现技术无关。也就是说，采用诸如Windows表单，WPF，Web表单等用户界面构建技术中的任意一种来实现View层，都无需改变系统的其他部分。

3、可以进行View的模拟测试。过去，由于View和Model之间的紧耦合，在Model和View同时开发完成之前对其中一方进行测试是不可能的。

参考资料来源：百度百科-MVP（MVP模式）

二、mvvm框架是什么?

MVVM（ModelViewViewModel）是基于MVC（ModelViewController）和MVP（ModelViewPresenter）发展起来的一种新的软件设计框架，并且其包含有WPF的特性。

在iOS应用开发中，常用的框架设计模式为MVC模式，控制器负责协调数据模型与视图之间的交互，除此之外，控制器还需要处理如场景转换、内存警告、键盘弹出等系统事件以及其他用户自定义的事件，所有的这些都放在控制器中，如UITableview的代理通常是控制器，而其中的UITableviewCell一般也设置控制器作为其代理，这些都造成了控制器中的代码臃肿，不利于程序的维护和扩展

iOS应用层架构之CDD

作者简介：高峰，6年iOS平台开发经验，曾就职于天猫无线，负责天猫iPhone客户端的研发工作，现在在创业，主要项目是SOMAMessenger，一款提供跨平台点对点加密的免费即时通讯工具。个人博客地址：http://mrpeak.cn/。

感谢作者高峰对本篇文章的授权。

从2010年开始接触iOS开发到现在，折腾过不少App的架构。从MVC到MVVM，VIPER，MVP，以及最新的ReactiveCocoa都做过实战尝试，还有其他变种，诸如猿题库iOS客户端架构设计，也做过一些学习研究。这些技术概念如果不熟悉，建议每个链接都点开好好研读下，不要对你的大脑太温柔。在开始架构讨论之前，再推荐一些其他非常值得一读的文章：唐巧－被误解的MVC和被神化的MVVM，CasaTaloyumiOS架构系列文章，objc.io架构系列文章。

1.应用层架构定义

其实严格来说，MVC和其他类似概念还算不上一个完整的架构。一个颇具规模的App必然会涉及到分层的设计，还有模块化、Hybrid机制、热补丁等等。MVC这种更像是个设计模式，解决的只是App分层设计当中的应用层（ApplicaitonLayer）组织方式。对于一些简单App来说，可能应用层一层就完成了整个App的架构，不用担心业务膨胀对后期开发的压力。这里我介绍一种新的应用层架构方式，名之为CDD：ContextDrivenDesign。

先明确下我们讨论的范畴，什么是一个App的应用层呢？现在不少App都会做一个分层的设计，一般为三层：应用层、Service层、DataAccess层。每一层再通过面向接口的方式产生依赖。

这是基础部分，不同的团队具体做法又会有一些差异。比如有些把DataAccess层又叫做Model层，有些把网络模块放在Service层，有些则放在DataAccess层，有些把部分的业务数据放到Model里面做成胖Model，有些则坚持使用瘦Model，把业务代码放在独立的地方统一管理，等等差异不一而足。除了分层还有一些公共模块的设计，比如数据库、网络、安全、热补丁、Hybrid机制、性能监测模块、日志模块等等如何配合分层设计，这里就不一一展开了。我们今天讨论的重点在应用层。

首先声明下，这个CDD其实是我很久之前看Android代码脑洞出来的，刚好解决了我之前组织应用层代码的一个痛点。做过Android的朋友应该都知道，在很多类里都可以通过getContext方法获取到一个context，再通过这个context可以获取到其他系统资源。当时我第一次了解完这个context概念的时候，瞬间产生了一个这样的脑洞：

我知道这灵光一闪的脑洞有点大，容我慢慢道来。前面提到应用层其实是在管理一堆UIViewController。拿微信做例子（我真的很喜欢拿微信举个栗子），首页4个tab，4个界面，4个controller，每个controller都有很多UI元素，点击又可以进入二级的controller，各controller可以看成一个独立的模块，有些简单，有些复杂。比如聊天界面这个controller就非常非常的复杂。先来看下聊天界面。

这个界面展示的UI元素非常之多，顶部导航栏，消息tableView，输入框部分，功能入口部分，可点击交互的部分也很多。如果我们把所有这些UI元素和交互的处理都放倒Controller里面，我们将得到一个著名的MVC（MassiveViewController），我曾经就有幸维护过一个这样controller，一个类文件一万多行代码，修起bug来十分的酸爽。很显然，我们的目标是拆分代码，所谓的架构不就是“以低耦合的方式分散业务复杂度”嘛。如果我们能把这些UI元素放倒不同的xxxView.m里面，交互的处理也有单独的类，目标达成。但新的问题是这些分散的各个类文件之间怎么交互，怎么耦合，怎么合体。MVC，MVVM，MVP等等都是在解决这个问题。这里我们团结各个类文件的方式是Context！建议再回看下上面的脑洞图。

在近一步深入讨论CDD之前，我们再重点强调下一个概念，dataflow（还有其他别名，infoflow，数据流等）。dataflow是架构优劣的测量标准，好的架构一定有清晰的dataflow，你说你架构怎么好，但dataflow说不清楚，No，No，我们不约。什么是dataflow，就是数据在你的App里流动的路线，就像人体血管里的血液，滋养着各个器官的运作。上面的聊天界面里，用户在输入框输入一个“hello”文本，文本被你包装成messagemodel，再保存到db，再发送到服务器，最后在界面上展示给用户，这就是一个完整的dataflow。实际的data经历的模块会更多，大部分的bug都是data除了问题，修bug时就是在顺着这个flow顺藤摸瓜，把脉诊断。

再问个问题，什么是data？你可以说data是model，是上面的“hello”文本。但我们还可以站在更高的角度来看待data，data是程序世界的基本元素，另一个基本元素是verb（动作），程序的世界里的所有存在都可以由这两个元素来描述，此处应该双手合十，进入冥想三分钟。推荐一篇大神吐槽Java的文章。

2.CDD架构详解

接下来进入正题，剖析CDD。我们先把应用层分解成三块任务：

在这三块划分的前提下我们再来制定CDD要达成的目标：

根据这些目标，我把脑洞图完善下就得到了下面一个更清晰的方案图：

到这里context的作用就很明显了，context可以把所有的子view都连接起来，可以把业务逻辑都导向同一个地方，可以把数据的管理都集中在一个类。所有的类都可以访问到context，但各部分只通过接口产生依赖，将耦合降至最低。至此CDD的大致结构就完成了，但还有一个问题需要解决。view的更新需要跟数据直接绑定，需要做成数据驱动的模式，类似MVVM。

但是我们怎么定义数据的变化呢？

做数据驱动的设计就一定要有一套规范去定义数据的变化，在应用层数据的变化我们可以主要分为两类。一是model本身property的变化，这种变化可以用KVO来监听，很方便。另一种是集合类的变化，比如array，set，dictionary等，这类变化又包括元素的增删替换，Objective-C没有提供原生的支持来监听这类变化，所以我们需要自己定一个子类，再通过重载增删替换方法来实现，在Demo中我就定义了一个CDDMutableArray。定义数据的变化十分关键，直接关系到我们怎么去设计dataflow。dataaccess层也需要定义一套规范，这里就不展开了。

CDD的dataflow是怎样的呢？

前面提到了dataflow是架构是否清晰的评判标准，是我们debug时的主要依赖。基于上面的讨论CDD的dataflow是这样的：

我之前提到说CDD解决了我之前的一个痛点，其实就是分散复杂度时，需要大量的delegate传递来连接各个类，很多地方都需要引用protocol，比如输入框view产生的“hello”文本要通过delegate传递给superview，superview可能还有superview，再到controller，controller再传递给业务处理的类，最后可能还要通过delegate做回传。但我们看下CDD的整个flow，Controller就像是一个旁观者，根本不需要参与到任何数据的传递，仅仅作为各个对象的持有者，只处理controller本身相关的业务，比如viewappear、disappear、rotate等，controller也是context的持有者，也可以在viewWillAppear的时候把事件传递到BusinessObject进行处理。

输入框view产生的“hello”文本，直接通过context传递到BusinessObject进行处理，生成的新消息message通过DataHandler插入到messagearray之后，直接通知到messagetableview进行刷新。方法调用的路径变短了，意味着调试的时候stepover的次数减少了。

这里有一点需要讨论下，view和context之间耦合的方式。view产生的数据要交给BusinessObject进行处理，那么这二者之间必然要产生耦合。耦合的方式有很多种：

3.CDD架构Demo实战

NoCode，NoBB。接下来我们用这套CDD的方案来实现一个类似微信的聊天界面。附上GitHubDEMO地址，与朋友们一起学习研究。

我们会通过Demo实现这样一个Controller：

这个demo主要实现两个功能来帮助大家了解CDD的workflow。一个是上面提到过的发送消息流程，二是点击头像之后可以进入用户详情的Controller，详情Controller里面可以改变用户的名字，改变之后聊天界面的MrPeak的名字也会以数据驱动的方式自动更新。

Demo实现细节：

CDD实现并不复杂，关键类如下：

CDDContext就是之前提到的核心类context，还包含CDDDataHandler，CDDBusinessObject基类的定义。

NSObject+CDD给每个NSObject对象添加一个CDDContext指针。

UIView+CDD则通过swizzling的方式给每个UIView自动添加CDD。

CDDMutableArray实现对Array的观察者模型。

针对某个Controller实现规范如下：

CDDContext，CDDDataHandler，CDDBusinessObject均在Controller当中生成。protocol定义接口部分的耦合。ViewModel是应用层当中的model，和View的展示通过KVO直接绑定。View部分则是我们拆分过后的子view。

4.CDD架构后续工作

CDD还处于初级阶段，是很久之前脑洞的产物，最近空一点才找机会把他变成代码。后面我会尝试在成熟的项目里去进一步完善并应证其合理性，也欢迎朋友们一起研究讨论。

后期可能进行的工作有：

第一时间掌握最新移动开发相关信息和技术，请关注mobilehub公众微信号（ID:mobilehub)。

【WINDRISES MINIPROGRAM PROMOTION】尊享直接对接老板

电话+V： 159999-78052

专注于小程序推广配套流程服务方案。为企业及个人客户提供了高性价比的运营方案，解决小微企业和个体拓展客户的问题