View层的架构

文章看自这里

View层组织注意事项

1. ViewController中的书写规范

   • 在viewDidLoad中做addSubViews和布局
   • getter和setter放到最后避免影响业务逻辑阅读
   • 将代理都写到一个delegate区域中，并且加上对应protocol名字
   • 为按钮点击事件等，单独开一个event response的区域

2. 建议使用全代码 不使用xib或者storyboard

3. 不建议统一派生ViewController，可以使用AOP或者使用NSObject的load函数(在应用启动时自动监听)，实现要实现的功能 --- 尽量不要使用继承

4. 能不放在Controller中做的事情就尽量不要放在Controller中做

View层应避免

1. 代码不规范导致混乱
2. 过多继承导致复杂的依赖关系
3. 横向依赖
4. 架构设计失去传承

制作好的View架构

要做一个View层架构，主要就是从以下三方面入手：

制定良好的规范
选择好合适的模式（MVC、MVCS、MVVM、VIPER）
根据业务情况针对ViewController做好拆分，提供一些小工具方便开发

MVC MVVM等设计模式

这些设计模式其实是 规定了架构中的3个角色:数据管理者，数据加工者，数据展示者,之间的数据如何交换

对mvc的一些总结

M应该做的事：

• 给ViewController提供数据
• 给ViewController存储数据提供接口
• 响应数据请求一般来时C的
• 提供经过抽象的业务基本组件，供Controller调度

M不应该这是dataModel 而是整个Model层

C应该做的事：

• 管理View Container的生命周期
• 负责生成所有的View实例，并放入View Container
• 监听来自View与业务有关的事件，通过与Model的合作，来完成对应事件的业务。

V应该做的事：

• 响应与业务无关的事件，并因此引发动画效果，点击反馈（如果合适的话，尽量还是放在View去做）等。
• 界面元素表达

MVVM

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

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

MVVM
viewmodel需要做的就是将json等数据转换为能给view用的model
Model层 这里的model层包括数据model层、网络请求层、数据存储层、

C负责View和ViewModel数据的绑定

MVVM就是讲MVC的C中的数据处理逻辑抽出来了

对于API的调用应该放在VM还是C中，看情况而定，如果你的请求独立于C，请求时不需要再联系ViewController就可以放在VM中，否则的话在VM中调用逻辑混乱，最好放在C中

RAC的目的1：View并不适合直接持有ViewModel。第二个目的就在于，ViewModel有可能并不是只服务于特定的一个View，使用更加松散的绑定关系能够降低ViewModel和View之间的耦合度