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好,便于将来拆分。

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

你可能感兴趣的:(iOSView层的组织方案)