在软件开发中，我们可以使用设计模式有效的解决我们软件设计中的常见问题。而在app的架构中，「structural」设计模式可以帮助我们很好的划分应用结构。
在本文，我们将使用「Repository」设计模式，访问各种来源的数据，如后端的API，蓝牙等等。并将这些数据转化成类型安全的实体类提供给上层（领域层），即我们业务逻辑所在的位置。
本文中我们将详细讲解「Repository设计模式，「包含以下部分」：」
- 「Repository设计模式」是什么以及何时使用它
- 使用「具体」和「抽象」类的实现以及如何权衡使用
- 如何使用「Repository设计模式」单元测试
1.什么是「Repository设计模式」
为了帮助我们理解，我们先看看下面的app架构设计图：
在这张图中，repositories位于 数据层（data layer），它的作用是：
- 将领域模型（或「实体）与」数据源（data sources）的实现细节隔离开来。
- 将数据源的数据对象「转换为领域层（domain layer）中使用的」实体或模型
- （可选）执行「数据缓存」等操作。
❝上图仅展示了构建APP的其中一种架构模式。如果使用其他的架构模式，例如 MVC、MVVM 或 Clean Architecture，虽然看起来不一样，但repository设计模式的应用都一样。 ❞
还要注意在**表示层（UI或Presentation）**中，widget是需要与业务逻辑或网络等是无关的。
❝如果在Widget中直接使用来自REST API 或远程数据库的key-value，这样做是有很大风险的。换句话说：不要将业务逻辑与您的 UI 代码混合，这会使你的代码更难测试、调试和推理。 ❞
2.什么时候使用「Repository设计模式」
「如果你的APP有一个复杂的数据层」，包含许多不同的数据来源，并且这些来源返回「非结构化数据」（例如 JSON），这样需要将其与其他部分隔离，这时候使用「Repository设计模式」非常方便。
如果说更具体的话，下面这些场景我认为「Repository设计模式」更合适：
- 与 REST API 交互
- 与本地或远程数据库（例如 Sembast、Hive、Firestore 等）交互
- 与设备的 API（例如权限、摄像头、位置等）交互
这样做的最大的好处是，「如果任何第三方API 发生重大更改，我们只需要更新Repository的代码」。
仅仅这一点就我就觉得使「Repository模式」 是100% 值得我们在实际中使用的。
