前言
MVC是软件工程中的一种软件架构模式，它把软件系统分为三个基本的部分：模型Model、视图View以及控制器Controller。这种模式的目的是为了实现一种动态的程序设计，简化后续对软件系统的修改和扩展，并使得程序的某一部分的复用成为可能。三个部分按照其各自的职责划分：
- 数据Model： 负责封装数据、存储和处理数据运算等工作
- 视图View： 负责数据展示、监听用户触摸等工作
- 控制器Controller： 负责业务逻辑、事件响应、数据加工等工作
在传统的MVC结构中，数据层在发生改变之后会通知视图层进行对应的处理，视图层能直接访问数据层。但在iOS中，M和V之间禁止通信，必须由C控制器层来协调M和V之间的变化。如下图所示，C对M和V的访问是不受限的，但M和V不允许直接接触控制器层，而是由多种Callbacks方式来通知控制器
本文旨在总结归纳笔者自己在开发过程中对于架构设计的理解，顺带一些笔者对控制器代码瘦身的总结。
在此声明，以下文章的观点为个人观点，如果你觉得笔者的观点存在问题，欢迎在讨论区交流。
如何分层
MVC是iOS开发者最常用的框架结构，即便是越来越热门的MVVM或是其他框架结构，几乎都是基于MVC模式下对各个组块的职责进一步的细化分层罢了。那么，在开发的时候如何制定三部分的层次划分呢？基本上所有的应用无非都是在做这些事情：
虽然上图不能囊括所有的应用，但是基本而言大众开发者干的活就是这些了。简单的根据这些事情来分工，我们可以很快的得出MVC和工作内容的对应关系：
|
1 2 3 |
controller 网络请求、事件响应 view 数据展示、动效展示 model 数据处理 |
通过对我们开发工作的分工，MVC架构的代码分层几乎已经可以确定了，下面笔者会对这三部分进行更详细的讲述
模型Model应该放什么代码
在以往开发中，对于模型层笔者存在这么几个疑惑：
- 模型Model只是一个纯粹的数据结构
- 负责数据I/O操作的操作属于
C还是M
第一个问题笔者认为原因在于认知错误，过往开发的过程中，笔者曾经一度认为数据和模型之间的转换属于业务操作，将这些处理放在控制器Controller层中执行：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
- (void)analyseRequestJSON: (NSDictionary *)JSON { NSArray *modelsData = JSON[@"result"]; NSMutableArray *models = @[].mutableCopy; for (NSDictionary *data in modelsData) { LXDRecord *record = [[LXDRecord alloc] init]; record.content = data[@"content"]; record.recorder = data[@"recorder"]; record.createDate = data[@"createDate"]; record.updateDate = data[@"updateDate"]; [models addObject: record]; } } |
这是典型的认知错误引发的代码错误放置的错误，对于这种情况，直接常见的做法是在Model中直接加入全能构造器Designed Initializer来将这部分代码转移至Model中：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
@interface LXDRecord: NSObject //properties - (instancetype)initWithCreateDate: (NSString *)createDate updateDate: (NSString *)updateDate content: (NSString *)content recorder: (NSString *)recorder; @end //Controller - (void)analyseRequestJSON: (NSDictionary *)JSON { NSArray *modelsData = JSON[@"result"]; NSMutableArray *models = @[].mutableCopy; for (NSDictionary *data in modelsData) { LXDRecord *record = [[LXDRecord alloc] initWithCreateDate: data[@"createDate"] updateDate: data[@"updateDate"] content: data[@"content"] recorder: data[@"recorder"]]; [models addObject: record]; } } |
在转移数据->模型这一逻辑处理之后数据层相对而言就充实的多，但这还不够。数据在完成抽象转换的工作之后，通常要展示到视图层面上。但往往模型还需要进行额外的加工才能展示，比如笔者曾经项目中的一个需求：用户在缴纳宽带费用后将宽带办理期间显示出来，这需求建立在服务器只有办理时间和办理时长两个字段。在MVC的结构下，将这部分代码放在C层会导致代码过多过于杂乱的后果，因此笔者将其放在Model中：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
@interface YQBNetworkRecord: YQBModel @property (nonatomic, copy, readonly) NSString *dealDate; //办理时间 @property (nonatomic, copy, readonly) NSString *effectTime; //办理时长 - (NSString *)timeOfNetworkDuration; iew以及控制器 Controller。这种模式的目的是为了实现一种动态的程序设计，简化后续对软件系统的修改和扩展，并使得程序的某一部分的复用成为可能。三个部分按照其各自的职责划分：
在传统的
本文旨在总结归纳笔者自己在开发过程中对于架构设计的理解，顺带一些笔者对控制器代码瘦身的总结。
如何分层
虽然上图不能囊括所有的应用，但是基本而言大众开发者干的活就是这些了。简单的根据这些事情来分工，我们可以很快的得出
通过对我们开发工作的分工， 模型Model应该放什么代码在以往开发中，对于模型层笔者存在这么几个疑惑：
第一个问题笔者认为原因在于认知错误，过往开发的过程中，笔者曾经一度认为数据和模型之间的转换属于业务操作，将这些处理放在控制器
这是典型的认知错误引发的代码错误放置的错误，对于这种情况，直接常见的做法是在
在转移
|
