标签：
上一次我们讨论了iOS重构在MVC项目上的可行性，今天具体来讲基于MVC的项目重构步骤以及重构后的结构。
思考要解决的问题
回到项目重构的问题上来,我认为项目重构首先要想清楚的问题:
项目层级如何划分?
大的业务场景有哪些?
将UIViewController归类为View还是Controller?
谁来负责网络请求,Model还是Controller?
从Model中取得数据后Controller怎么把数据传递给View去展示?按照View层级逐级传递?是否需要使用ViewModel?
Model的生命周期怎么控制?(全局Model和私有Model的划分)
View层级结构越来越深时,怎么传递用户的交互操作?(毫无疑问NSNotification)
UIViewController的划分
本次重构中还是将UIViewController归类为C层,但是为了将UIViewController彻底和UIView分离开,命名上我们直接使用XXXController,我们对每一个XXXController设计了一个对应的名为的XXXContainerView的UIView对象,所有的view布局都会在这个XXXContainerView中完成.
项目目录结构
重构后的项目目录结构如下:
一级目录 子目录 目录说明
Macro 存放开发过程中所需的一些宏定义
Category 存放不涉及业务,用来辅助开发的分类
Tools 不同的业务工具类 存放涉及轻量级业务的处理类,比如根据不同业务格式化输出不同的字符串
Views 不同的业务模块页面名 存放不同业务模块页面下的V
Controllers 不同的业务模块页面名 存放不同业务模块页面下的C
ViewModels 不同数据模块名 数据翻译层,将DataInfo数据翻译为View可直接展示的数据,但本次重构中由于时间因素不强制使用
Model PublicModel 公用的全局Model,比如用户信息UserModel
MoudleModel 单独某个模块使用的私有Model,只负责私有业务
Services 不同的Service 提供底层服务,例如HttpService,SecurityService
业务场景划分
由于之前赶进度开发,没有做具体的功能拆分.本次重构之前使用了 StartUML 绘制了主要场景下的UML图,包括类图,时序图,流程图.
强烈推荐新项目正式编码之前就完成这一步,并由前后端技术负责人主持进行UML评审.所有涉及到的业务Model的property以及public方法,所有DataInfo类的属性,甚至所有的Controller都会在绘制UML的过程中产出.当然,要想绘制所有场景下的UML图可能耗时比较久,一般来说只要绘制出主要交互场景即可.
网络请求
在手机端基本上所有的网络请求都是跟业务挂钩的,显然放在Model里更合适.至于请求完成后的回调就看个人习惯了,delegate或者block都是可行的.
后续
由于时间原因,并没有写出具体的示例代码,之后会针对一个示例场景,写出我理解中的各个MV(X)模式的参考代码,期待成文后与同行探讨.
MVVM扩展
放一张MVVM的示意图:
看上去是不是很像MVP?只是多了View和ViewModel的双向绑定,这里强调一点,RAC不一定登陆MVVM,MVVM也不一定要使用RAC.想了解更多有关iOS开发（http://www.maiziedu.com/course/ios/），学习更多知识。
标签：