之前有一个需求是这样的：需要前端自己设计一个图片（或者音视频文件）上传、拉取、修改的框架。
具体的需求：
1.用户可以上传音频、视频、图片文件；
2.可以同时删除和上传一起提交；
3.失败之后仅对于失败文件（不区分是上传还是删除）让用户选择是否重新操作，并给出哪一个文件出现失败；
4.目前需求是不限制用户上传的张数（因为是一些证明之类的文件），但后期可能出现“一个萝卜一个坑”（事实证明不到一个月的时间就出来了）；
此时我拿到的就是后台给的两个接口文档--上传和删除，如何处理这些UI、页面交互和网络模块的逻辑是个很大的问题，没有一个线贯穿整个流程的话很容易做着改着到最后一团乱麻。这个线我就选择了模型。
如何设计呢？那就是为这个模型添加一些状态，所有的组件的变化都根据这些状态来走，而不用管我是怎么处理的。简单地说，就是我只对Model操作，其他的跟随者Model走。然后分离一些模块，例如网络请求部分，最后处理下View、VC和Model之间的联系。
Model的设计，也就是整个流程的主线的操作。这里我为它添加了一些状态：
/**
一级判断,是否是服务器上的图片,默认为NO，YES状态的模型可被标记为待删除
*/
@property (nonatomic,assign) BOOL isOriginal;
/**
二级判断
isOriginal == YES && type == delegate 删除状态 -- 提交 待删除 状态到服务器 || 成功 -- 遍历直接删除|| 失败 -- 状态不变可再次提交删除
isOriginal == NO && type == add -- 提交 新增 状态到服务器 || 成功 -- isOriginal = YES || 失败 -- 状态不变可再次提交新增 // 页面中可直接删除无服务器交互
*/
@property (nonatomic,copy) NSString *type;
/**
三级判断 是否删除成功
*/
@property (nonatomic,assign) BOOL isDeleteOK;
/**
三级判断 是否添加成功
*/
@property (nonatomic,assign) BOOL isAddOK;
在整个流程中，我主要围绕着这些状态来操作，也主要操作这些状态。
View与Model：
collectionview随着model的个数去增加删除model，cell随着model的状态去改变可变的视图(例如显示待删除的标记等等)。view基本上不去对model进行操作。
VC与Model：
VC->Model的操作主要涉及添加删除时的状态改变、整理装model的容器、调出网络模块、处理block回调中的Model状态等等。model基本上不去对VC进行操作。
这中间VC对Model的操作是主要的部分。VC要从Model的alloc开始，不停地根据用户的交互变化Model的状态，然后打包（筛选要进行操作的Model装到容器中）准备上传/删除操作，最后根据回调改变Model的状态刷新UI。
所以整个流程中，只需要把控对Model的操作就可以。为了能更好的扩展到各种类型的文件，我们创建一个基类的Model，再为每种类型的文件专门建立一种Model继承自基类的Model，利用工厂模式生产对应的cell，这样就把任务从控制器中分离到各个cell中。
对于业务逻辑复杂的流程，我们大部分都可以以Model作为主线，记得刚敲代码的时候曾经问过为什么要引入模型，听别人解释了很多还是觉得没必要非要把字典中的值放到模型里。现在对这些当然有了自己的理解和思维。
良好地利用Model能让复杂的事情变得简单，它就像一个工人一样，你为它扩展更多的装备，指挥它做好事情。
网友评论