当我们点击一个button的时候,有2条平行线,一条是打开一个界面(view),另一条是一个网络请求.

异步等待数据:

打开一个界面但是服务器数据没有返回,这时的界面会显示空白,可以做提示,等到服务器数据返回进行数据刷新.好处是不卡主线程,界面仍然流动,坏处是需要多在下一个界面做提示信息,并且处理多线程问题.

同步等待数据:

点击button展示一个loading的提示框,等待服务器返回数据,数据返回之后,再将数据传输到界面直接进行展示.好处是节省资源与时间,坏处是用户体验可能不好,网络延迟时,会造成用户流失率严重.

请求时机:

当点击button的时候,后面的连续响应链,是在哪个响应链/响应点上面去请求,是个极大的问题,需要多做考虑.如:点击button的一瞬间,界面打开一瞬间,刚打开的时候,打开完毕之后,稍等个几秒再做请求,都是需要和设计模式契合才能带来效率,不然就是个天坑.

回调方法:

1:回调方法是和请求方法写在一起,即C++中的lambda表达式,C#中的匿名函数,C中的指针函数,OC中的block块,Lua中的方法传递等等,好处是不用再费力去寻找回调方法了,直接从请求那个点向下一直写代码,坏处是对此语言机制不理解,造成内存泄露以及其他问题等.

2:回调方法和请求方法不写在一起,并且分割开来,分文件或者分区域写.好处是代码看起来不杂乱,不会出现语言机制的错误(因为这样很容易做),并且可以使用设计模式进行操作,坏处是,如果没有文档,只有函数调用,你需要花时间去寻找其中的请求方法/回调方法,然后打log进行一步一步解析,在不好的设计模式中,极大的耗费程序员的精力.

解析数据:

1:写在网络请求回调的地方.好处是清晰可见,坏处是代码量臃肿,不能很好的配合设计模式.

2:单独操作数据解析,做法就是写一个公用类,哪里需要哪里调.好处就是封装,不需要调用者知道,坏处是公用类方法很多,有理解不清晰的问题.尤其写lua时,没有规范很容易出现此类问题,消耗时间.

数据保存:

1:数据保存在当前界面的属性上面.好处是使用方便,更改方便,坏处是不符合设计模式,不规范没有MVC的设计思想.

2:数据保存在model中,保存在model中需要在controller里面解析出来,利用方法传递给view层,更新界面,如果将model数据传递给view层,完全破坏了MVC设计模式,更不能直接属性传递,然后刷新.需要保持view的洁净,完全就是view里面的操作,不包含一点数据.与外部操作只用方法/通知/观察等互通有无.