背景介绍
用Swift代替Object-C
用protocol代替基类
用MVVM给ViewController减负
MVVM取舍
对于每个场景Scene，用4个类来完成功能
XXXView：Storyboard、UIView一级继承子类，做页面展示
XXXViewController：UIViewController一级继承子类，调度者，不做具体工作
XXXViewModel：显示逻辑，结构体，将页面资源转化为数据信息
XXXLogic：Classs，不要继承任何类，做业务逻辑放弃双向绑定，不引入RxSwift等第三方库
对ViewModel进行属性观察，将对界面的修改转化为对ViewModel中数据的修改，算是一种简单的单向绑定。
ViewModel用struct，一种是数据结构（感觉上比较小），做简单的显示逻辑，对应于cell，某个具体的视图等等，名字和视图名字保持一致，添加ViewModel后缀；另一种是容器（感觉上比较大），比如对应表格视图，可以用来做表格的代理和数据源的管理者。
表格的代理不要让ViewController做，而是让同级别的ViewModel来做
表格的Cell其实是View，需要对应一个ViewModel。ViewModel不是跟UIViewController对应，而是跟UIView对应。将界面展示转化为ViewModel这结构体数据信息。
从网络取数据，用户输入信息合法话检查等业务逻辑全部放入Logic中做。
Logic也推荐用struct，相当于容器（比较大），可以是模块级的。当然继承自系统API的当然用class。
从单体应用到多部门合作的平台型应用，把Logic部分抽出来，放入统一的framework中，进行统筹安排。参考service的概念，中间的接口用protocol定义，降低耦合度。
引入service分层机制之后，ViewModel留在界面层，这里的protocol主要用在公共控件中，其他地方还是让ViewModel作为一个view的数据适配，一般不用考虑复用。而Logic部分，定义protocol，由于framework的阻隔，protocol的定义和默认实现（扩展protocol）在service的framework中，在界面层，直接一个类型为protocol的weak属性，进行使用就可以。
引入service概念，主程序和插件之间（当然也可以扩展到其他模块，只要情况适用）信息传递也可以参考HTTP协议中关于url的定义 scheme://host?key1=value1&key2=value2
参考文章
LucidDreams: Protocol and Value Oriented Programming Sample Code
