ios 浅谈MVC模式

很多客户端研发一直在使用苹果推荐的MVC架构模式。MVC从应用层面进行分层开发,极大优化了我们的代码结构,简单易上手,很容易被程序员所接受。程序员刚接手一个新项目,如果是MVC的架构模式,会减少代码熟悉时间,快速的进行开发和维护工作,实际上对于多人开发维护的项目,MVC仍然是非常好的架构模式,这也是这种架构模式经久不衰的原因。
但是任何事物都有两面性,随着项目需求的增加,业务逻辑、网络请求、代理方法等都往Controller层加塞,导致Controller层变得越来越臃肿,动辄上千行的代码量绝对是维护人员的噩梦,因此在MVC基础上逐渐衍生出来了MVP、MVVM等架构模式。具体在业务开发中使用哪种模式需要你自己去衡量。

传统的MVC设计模式

M: Model 数据层,负责网络数据的处理,数据持久化存储和读取等工作
V: View 视图层,负责呈现从数据层传递的数据渲染工作,以及与用户的交互工作
C: Controller控制器,负责连接Model层跟View层,响应View的事件和作为View的代理,以及界面跳转和生命周期的处理等任务

 用户的交互逻辑

用户点击 View(视图) –> 视图响应事件 –>通过代理传递事件到Controller–>发起网络请求更新Model—>Model处理完数据–>代理或通知给Controller–>改变视图样式–>完成

可以看到Controller强引用View与Model,而View与Model是分离的,所以就可以保证Model和View的可测试性和复用性,但是Controller不行,因为Controller是Model和View的中介,所以不能复用,或者说很难复用。

上面的内容中,已经详细描述了model、view和controller之间如何各司其职(即该是谁的东西,谁就要保护好,不能让另外一个越俎代庖的去处理)。MVC模式虽然是iOS编程中使用最广泛的模式,但论起复杂程度,MVC模式可以算是众多设计模式之首。通常情况下,MVC模式需要综合使用target-action模式、delegate模式、Notification或KVO模式等。下图是斯坦福大学的iOS一堂关于iOS介绍的公开课上所使用的示例图,这张图像也生动的描绘出来了MVC模式的工作原理,接下来的原理讲解也是依托于这张图像:

1、 Controller和View之间可以通信,Controllor通过outlet(输出口)控制View,View可以通过target-action、delegate或者data source(想想UITableVeiwDatasource)来和Controller通信;

2、 Controller在接收到View传过来的交互事件(View就是完成让人和程序的交互的呀,比如按B1按钮)之后,经过一些判断和处理,把需要Model处理的事件递交给Model处理(比如刚才的例子中的保存到数据库),Controller对Model使用的是API;

3、 Model在处理完数据之后,如果有需要,会通过Notification或者KVO的方式告知Controller,事件已经处理完,Controller再经过判断和处理之后,考虑下一步要怎么办(是默默无闻的在后台操作,还是需要更新View,这得看Controller的“脸色”行事)。这里的无线天线很有意思,Model只负责发送通知,具体谁接收这个通知并处理它,Model并不关心,这一点非常重要,是理解Notification模式的关键。

4、 Model和View之间不直接通信!

       按照上面的原理,我们知道了M、V、C之间的各司其职——Model不保存控件,View不做数据库操作(但这个也不是绝对,如果需要View做一些数据缓存工作,还是需要保存一些临时数据的),而Controller就充当了两者之间的协调器。  

参考例如:https://www.jianshu.com/p/4b94de458c0d?utm_source=desktop&utm_medium=timeline