iOS基于MVC的项目重构总结

iOS中的MVC和MVP

Cocoa版本的MVC

Cocoa版本的MVC
根据官网的描述,Cocoa中的MVC是这样的
iOS基于MVC的项目重构总结_第1张图片
cocoa版MVC.png
- model objects Encapulate Data and Basic Behavious
- View Objects Present Informaiton to the User
- Controller Objects Tie The Model to the View

C 和P的差别

通过搜索引擎,发现其实MVP有两种
1.Passive View
2.Supervising Controller

网上绝到多数部分谈论MVP的文章谈论的其实都是Passive View。这里放上一张Passive View的示意图

iOS基于MVC的项目重构总结_第2张图片
MVP的Passive View的示意图.png

简而言之.MVP就是view驱动的,View层持有对应Presenter的引用,View上的交互事件首先会调用Presenter提供的接口,人后Presenter调用Model提供的方法取得数据,最后presenter将取得的数据传递到View上展示
MVC则是由controller驱动的,controller持有的view,并相应view上的交互事件,根据交互调用不同的Model方法取得反馈数据,在将数据传递到view展示。

就我个人而言,我的理解是。MVP是用户视角,所见即View,MVC是程序员视角,:I control everyone.
理解MVC和MVP的差别困惑的地方在于。,UIViewController到底是属于C(P)层还是V层呢?下面将分别具体分析一下这两种观点

  • 观点一,uiview controller的归属-->view
    如果把UIViewController视为V层,即上面MVP示意图中的Passive View,那么UIViewController将只负责View布局相关逻辑,不涉及任何与Model层的交互!!

所有的业务逻辑交互通过UIViewController持有的Presenter与Model间的调用来完成

观点二:UIViewController的归属--->Controller

那如果把UIViewController视为C层,从MVC设计理念上来说,C层不会负责具体View的布局及展示逻辑,但是由于iOS中UIViewController的特殊设计,导致很多开发者直接就在UIViewController包含了很多具体布局相关的代码,更可怕的情况是不止是View的初始化,包括网络请求及具体业务处理也被包含到UIViewController中,这也许就是有人戏称MVC为:MassiveViewController的原因

本次基于MVC的项目重构步骤

思考要解决的问题
回到项目重构的问题上来,我认为项目重构要想清楚的问题:
1,项目层级如何划分的。
2,大的业务场景有哪些?
3,将UIView Controller归类为View还是Controller
4,谁来负责网络请求,Model还是Controller?
5,从Model中取得数据后Controller怎么把数据传递给View去展示?按照view层级主机递增?是否需要使用View Model
6.Model的生命周期怎么控制?(全局和私有Model的划分)
7,View层级结构越来越深时,怎么传递用户的交互操作?(毫无疑问是NSNotification)

UIview Controller的划分

本次重构中还是UIview Controller归类为C层,但是为了将UIview Controller彻底和UIview分离开。命名上我们直接使用XXXController。我们对每一个XXXController设计了一个对应的名为的XXXContatinerView的UIView对象。所有的view布局都会在这个XXXControllerView中完成。

iOS基于MVC的项目重构总结_第3张图片
屏幕截图.jpg
业务场景划分

由于之前赶进度开发,没有做具体的功能拆分.本次重构之前使用了StartUML绘制了主要场景下的UML图,包括类图,时序图,流程图
强烈推荐新项目正式编码之前就完成这一步,并由前后端技术负责人主持进行UML评审.所有涉及到的业务Model的property以及public方法,所有DataInfo类的属性,甚至所有的Controller都会在绘制UML的过程中产出.当然,要想绘制所有场景下的UML图可能耗时比较久,一般来说只要绘制出主要交互场景即可.

你可能感兴趣的:(iOS基于MVC的项目重构总结)