8、Ruby 开发中的抽象层与查询对象实践

Ruby 开发中的抽象层与查询对象实践

服务对象的利与弊

服务对象模式常被用于防止控制器和模型臃肿。在实际开发中，当我们不确定将代码放在何处时，往往会选择在 app/services 文件夹下创建文件。然而，这种基于文件夹的思考方式存在缺陷。它可能导致在任何不明确的情况下都创建服务，而忽略了代码在应用中的角色应由其所属的抽象层来定义。

过度使用服务对象可能会导致贫血模型的出现。当模型仅承担对象 - 关系映射（ORM）或数据封装的功能，而不包含任何业务逻辑时，就形成了贫血模型。这是一种反模式，因为它消除了面向对象（OO）方法的优势，而倾向于过程式代码。

为了解决服务对象带来的概念复杂性问题，我们可以将 app/services 文件夹看作代码的“候车室”。在相应的抽象出现之前，代码可以暂时存放在这里，但要注意不要过度拥挤。同时，不要过早进行抽象，因为好的抽象需要一定的时间来证明其价值。将 app/services 分解为几个明确定义的抽象可以降低概念复杂性。

分层架构与抽象层

分层架构是一种将应用组件/功能分离为水平逻辑层的架构模式。数据从顶层到底层单向流动，各层不依赖于其上的层。常见的分层架构包括四层：
| 层次 | 职责 |
| ---- | ---- |
| 表示层 | 处理用户交互并通过 UI 向用户展示信息 |
| 应用层 | 组织领域对象以满足特定用例 |
| 领域层 | 描述实体、规则和不变量等，维护应用状态 |
| 基础设施层 | 包含支持技术，如数据库、框架和 API 客户