《论MVVM伪框架结构和MVC中M的实现机制及M层的构建》阅读笔记
原文链接
* 业务类中的属性设计为只读。
* 数据模型类中的属性定义最好也设置为只读，因为数据模型的建立是在业务类方法内部完成并通过通知或者异步回调的方式交给使用者。而不应该交由使用者来创建和更新。
* 数据模型类一般提供一个带有所有属性的init初始化方法，而初始化后这些属性原则上是不能被再次改变，所以应该设置为只读属性。
- 优秀的框架中各层次的拆分并不是简单的将代码进行归类和划分，层次的划分是横向的，而模块的划分是纵向的。
- 视图负责展示和渲染，模型负责业务逻辑的实现，控制负责调度视图的事件以及业务逻辑的调用以及通知视图的刷新通知。
- 不能将M层简单理解为干巴巴的只有属性没有方法的数据模型。
- M层是业务模型层而非数据模型层。
- 优秀的应用和框架并不在代码的多寡，而是整体系统的代码简单易读，各部分职责分明，容易维护和调试。
- M层要完成对业务逻辑实现的封装，一般业务逻辑最多的是涉及到客户端和服务器之间的业务交互。M层要完成对应用网络协议和服务器之间的交互数据格式，本地缓存和数据库存储等所有业务细节的封装，这些东西不能暴露给C层，只给其提供一个接口。
- C层的作用就是处理视图的事件，然后调用业务逻辑，接收业务逻辑的处理结果通知，然后通知视图去刷新界面。
- M层是生产者，负责数据的构建和更新，C和V层负责数据的使用和消费。
- C具有负责创建并持有M层对象的责任，C层也是一个使用观察者。
- C层负责M层的方法调用。
- C层负责观察M层的数据变化通知并进行相应处理。
M应该做的事：
给ViewController提供数据
给ViewController存储数据提供接口
提供经过抽象的业务基本组件，供Controller调度
C应该做的事：
管理View Container的生命周期
负责生成所有的View实例，并放入View Container
监听来自View与业务有关的事件，通过与Model的合作，来完成对应事件的业务。
V应该做的事：
响应与业务无关的事件，并因此引发动画效果，点击反馈（如果合适的话，尽量还是放在View去做）等。
界面元素表达
delegate这种模式并不局限于M和C之间，同样也可以应用在V和C之间。
delegate本质其实是一种双方之间通信的接口，而通过接口来进行通信则可以最大限度的减少对象之间的耦合。
除了delegate外也可以采用Block异步通知方式
typedef void (^BlockHandler)(id obj, NSError *error);
采用block方式定义异步方法时一般要符合如下几个规则：
-
BlockHandler的参数确保就是固定的2个：一个是异步方法返回的对象，这个对象可以根据不同的方法而返回不同的对象。一个NSError对象表示异步访问发生了错误的返回。 - 将
block回调处理作为方法的最后一个参数。 - 不建议在一个方法中出现两个block回调：一个正确的和一个失败的。
- 推荐：对于在M层对象中 某个请求通过
block回调来通知调用者进行异步更新的机制。一个原则，只要涉及到M层对象的方法调用都尽可能走标准block回调这种方式。例如：
- (void)fn1:(参数类型)参数 callback:(BlockHandler)callback;
- (void)fn2:(参数类型)参数 callback:(BlockHandler)callback;
- (void)fn4:(参数类型)参数 callback:(BlockHandler)callback;
- (void)fn5:(参数类型)参数 callback:(BlockHandler)callback;
上面的方法实现和调用机制看起来都很统一而且是标准化。即使某个方法并没有任何异步动作，也最好遵守这种模式，因为某天有可能会从同步实现变为异步实现。这样的话只需改动C层的代码即可。
delegate异步通知和Block异步通知的选择参考：
- 如果某个类中具有很多个方法，而每个方法又实现了不同的功能，并且方法的异步返回数据和这个方法具有很强的关联性就应该考虑使用
block而不是delegate。 - 如果类中的方法的异步方法是那种一次交互就得到一个不同的结果，而且得到的结果和上次结果没什么关联，就考虑使用
block而不是delegate。 - 如果我们调用类中的某个方法，而调用前设置了一些上下文，而调用方法后我们又希望根据这个上下文来处理的返回结果时，就考虑使用
block而不是delegate。 - 如果我们调用类里面的某个方法，而返回的结果不需要和上下文进行关联那么就考虑使用
Delegate而不用block。 - 如果要实时的观察业务类里面的某个属性的变化时，我们就应该考虑使用
Delegate而不是使用block。 - 如果业务类里面的异步通知可能分为好几个步骤那么就考虑使用
Delegate而不是使用block。
什么场景下用KVO的方式实现异步通知回调：
- 某个对象的同一数据更新可能会引起多个依赖这个对象的对象的更新变化处理。
- 如果某个对象的生命周期要比观察者短则不建议用KVO的方式，因为这个有可能会导致系统的崩溃而造成巨大的影响。
delegate和block的缺点
-
delegate的方式必须要事先定义出一个接口协议来，并且调用者和实现者都需要按照这个接口规则来进行通知和数据处理交互，这样无形中就产生了一定的耦合性，也就是二者之间还是具有隐式的依赖。不利于扩展和进行完全自定义处理。 -
block的缺点：- 是使用不好会产生循环引用的问题
- 出错后难以调试以及难以进行问题追踪
- 代码中产生多重嵌套，从而影响代码的美观和可读性
KVO机制的优点
业务对象和观察者之间完全脱离了耦合性，而且数据变化后的通知完全由系统来处理，不需要添加附加的代码和逻辑，而且可以实现多观察者同时监听一份数据。
缺点：只能对属性的变化进行观察。
NSNotification缺点
这种机制过于松散，没有关联的上下文。给使用者带来了一定的学习成本。
总结
在设计一个业务层时，首先应该要对业务进行仔细的分析和理解，然后构建出一个类结构图，这种静态框架设计好之后，就需要对类进行角色和职责划分，哪些应该设计为数据模型类，哪些应该设计为业务类。
