iOSView层的组织方案

这篇文章主要是一个学习记录，学习了这个

1.view代码结构的规定

每一个view都应该有一个统一的代码结构，不然代码看起来非常凌乱，不同类型的方法散乱摆放也不容易查找。这篇文章推荐的view的代码结构是这样的：

首先，每个程序员都应该遵循苹果官方给出的代码规范：官方代码规范

其次，viewcontroller的代码差不多是这样：

view层的代码结构

需要注意的是：

不要在viewDidLoad方法里初始化控件，所有的控件都应该在getter方法里初始化（懒加载）。

在viewDidLoad方法里只进行addSubview的操作。

在viewWillAppear方法里做布局的操作，用autolayout布局可以使用Masonry框架

在viewDidAppear方法里添加Notification等操作。

getter方法放在最后，因为一个界面里可能有很多个view，把getter方法全写在最前面看起来很不方便。

2.是否为了保证ViewController的统一，而让业务方统一派生ViewController

作者给出的答案是否定的，比如说本来所有的ViewController都继承自UIViewController,但是架构师为了让所有的ViewController遵循一套统一的逻辑，封装了一个TMViewController,所有的ViewController都继承自它。作者认为这样是没有必要的，这样做集成成本增加，业务方的上手成本也会增加。

正确的做法是：

不通过业务代码上对框架的主动迎合，使得业务能够被框架感知。细化下来就是两个问题，框架要能够拦截到ViewController的生命周期，另一个问题就是，拦截的定义时机。

对于方法拦截，很容易想到Method Swizzling，那么我们可以写一个实例，在App启动的时候添加针对UIViewController的方法拦截，这是一种做法。还有另一种做法就是，使用NSObject的load函数，在应用启动时自动监听。使用后者的好处在于，这个模块只要被项目包含，就能够发挥作用，不需要在项目里面添加任何代码。

3. MVVM

MVVM是认为Controller做了太多数据加工的事情，所以MVVM把数据加工的任务从Controller中解放了出来，使得Controller只需要专注于数据调配的工作，ViewModel则去负责数据加工并通过通知机制让View响应ViewModel的改变。

MVVM是基于胖Model的架构思路建立的，然后在胖Model中拆出两部分：Model和胖Model。

前面说MVVM把数据加工的任务从Controller中解放出来，跟MVVM拆分的是胖Model也不矛盾。要做到解放Controller，首先你得有个胖Model，然后再把这个胖Model拆成Model和ViewModel。

什么是胖Model呢？

胖Model就是在model里添加了部分弱业务逻辑，让controller从model拿到数据以后不需要做过多的修改，就可以直接显示在view上。弱业务逻辑是一些很少更改的业务，而且弱业务逻辑重复出现的概率比强业务逻辑大。把弱业务逻辑写在view里，就避免了把很多相同的弱业务逻辑写在很多个不同的ViewController里。

ViewModel是做什么事的呢，就是作胖Model做的事，弱业务逻辑。

MVVM模式中是必须要有Controller的，严格来说是MVCVM。Controller夹在View和ViewModel之间做的其中一个主要事情就是将View和ViewModel进行绑定。在逻辑上，Controller知道应当展示哪个View，Controller也知道应当使用哪个ViewModel，然而View和ViewModel它们之间是互相不知道的，所以Controller就负责控制他们的绑定关系，所以叫Controller/控制器就是这个原因。

为什么要使用ReactiveCocoa？

不使用ReactiveCocoa一样可以实现MVVM。使用ReactiveCocoa只是为了让为了让View和ViewModel之间能够有比较松散的绑定关系。苹果本身没有提供一个适合这种绑定的方法，而ReactiveCocoa提供的RACSignal非常优雅的实现了这种松散的绑定。

4.设计的基本原则

1.尽可能减少继承层级，涉及苹果原生对象的尽量不要继承。Category是苹果提供的最好的使用集合代替继承的方案。少用继承的两个好处：1. 在业务方做业务开发或者做Demo时，可以脱离App环境，或花更少的时间搭建环境。2. 对业务方来说功能更加透明，也符合业务方在开发时的第一直觉。

2.做好代码规范，规定好代码在文件中的布局，尤其是ViewController。

3.能不放在Controller做的事情就尽量不要放在Controller里面去做。我们要稍微转变一下思路：模棱两可的模块，就不要塞到Controller去了，塞到V或者塞到M或者其他什么地方都比塞进Controller好，便于将来拆分。

这个作者吧，太厉害了，他写的好多东西我都看不懂。。。