服务化概念

• 将后台的服务化思路借鉴到客户端
• 分为微服务和服务两种类型
• 微服务的定义是只供调用，不调用其他人
• 服务的定义是既对外提供服务，又调用其他人的服务
• 在iOS客户端，可以不区分微服务和服务，统一称为服务，xxxService

单例还是类方法？

可以说单例和类方法都可以，两者也都有优缺点。

• 单例可以有自己的属性，调用方便
• 类方法在实现某些功能的时候受限，因为没有成员变量或者是数据啊
• 类方法是最简单的调用方式，只要一个类名就可以了
• 类方法可以调用单例，实例方法；而单例再套一个类方法感觉有点奇怪
• 单例的统一方法，一般都是sharedInstance，反复写感觉有点浪费
• 使用者并不关心是单例还是实例，这是实现层面的内容

选择建议：

• xxxService统一采用类方法对外提供功能
• 统一用函数的方式提供功能，放弃属性的方式
• xxxService作为一层接口封装，只做调度，没有具体实现
• 具体功能由单例或者实例对象提供，数据由实现者持有

普通三层

• iOS的Native部分，大致可以分为数据，逻辑和界面三层，这是符合常见思维的
• 界面层入手最简单，不过经历多了之后，就会发现，界面层其实是最麻烦的
• iOS程序一开始都很小，不存在分层的概念，所有的事情在一个UIViewController完成。而且设计思路是代理模式，系统为开发者提供了一些代理函数来自定义行为。每个页面代表一个UIViewController，大家都差不多，只是具体内容由应用开发者自定义。每次也只有一个页面在显示，其他的要么在排队，要么没加载。
• 后来，随着业务逻辑的增长，UIViewController就变成了“上帝类”，什么都做，难复用，维护困难
• 所以，后来出现了iOS架构的概念，把一些跟业务无关的内容抽出来，提高复用度，逐渐形成逻辑层，数据层的概念
• iOS架构的核心，一般都是为UIViewController瘦身。因为它什么都能做，所以目标是让它“什么具体的事情都不做”，只做一个“调度者”，就像一个“企业的CEO”一样，专门负责“按开关的”
• UIViewController是系统的代理，属于界面层，难复用，所以界面层入手简单，其实是最复杂的
• 既然要界面层本质上是最复杂的，那么iOS架构的界面层要尽量薄
• 逻辑层一般是按照业务概念来分的，比如登录，注册，订单等
• 数据层一般是按照功能来分的，与具体业务无关，比如网络，数据库，加解密等等
• 在模式上，参考Object-C到Swift的发展，偏向于用组合代替继承。一般有BaseUIViewController的，很难称得上是优秀的架构