1 基本概念
1.1 定义
仓储模式是一种面向对象的软件设计模式，用于封装数据访问逻辑。它在领域对象与底层存储之间建立一层抽象，让外部通过统一接口完成对象的获取、保存、更新和删除，而不必直接处理数据库、文件或其他持久化机制。
从使用者角度看，仓储像一个“对象集合的中介”，业务代码只需关心对象本身及其行为，至于数据如何映射、存放和检索，则由仓储负责协调。
1.2 核心目标
仓储模式的主要目标是隔离业务逻辑与数据存取细节，使系统结构更清晰。它通常追求以下几方面效果：一是让领域层专注于业务规则；二是让数据访问实现可以替换；三是让查询与保存操作具有一致的入口；四是为单元测试提供更容易替代的依赖。
1.3 适用场景
仓储模式常用于对象数量较多、数据读写频繁、领域逻辑相对明确的系统中。它尤其适合需要将业务规则与数据库操作分开的场合，例如订单管理、内容管理、库存系统等。
在采用领域驱动设计的项目里，仓储常被视为聚合根的主要访问方式；在依赖注入体系中，它也便于将具体存储实现与业务代码解耦。
1.4 与数据访问层的关系
仓储模式与数据访问层密切相关，但两者并不完全等同。数据访问层强调对存储介质进行操作，往往围绕表、记录或查询语句展开；仓储模式则更偏向领域对象，强调以对象为中心组织访问行为。
也就是说，数据访问层解决“怎么读写数据”，仓储模式更强调“以什么方式向业务提供数据”。在实际工程中，仓储可以视为数据访问层的一种对象化表达。
2 设计原理
2.1 抽象存取
仓储模式的基础在于将具体存取手段抽象出来。调用方只接触仓储接口，不直接面对 SQL、文件路径、缓存键等底层细节。这样一来，存储介质变化时，业务代码通常无需改动。
2.2 领域对象隔离
仓储负责在领域对象与持久化模型之间建立缓冲区。领域对象可以保持更自然的业务结构，不必为了数据库字段而频繁妥协。相应地，仓储在内部完成对象与存储记录之间的转换，使领域逻辑保持整洁。
2.3 接口与实现分离
仓储模式通常将接口与实现拆开。接口定义系统对外能做什么，实现则决定具体怎么做。这种分离让替换存储技术、模拟测试环境或引入新数据源都更为方便。
2.4 统一查询入口
仓储常被设计为统一的查询入口，所有与某类对象相关的访问都汇聚到同一处。相比在各个业务模块里零散编写查询语句，这种方式更容易形成一致的访问策略，也便于集中管理缓存、事务和性能优化逻辑。
3 组成要素
3.1 仓储接口
仓储接口定义可用的操作集合，通常包含保存、查找、删除以及条件查询等方法。接口设计越稳定，业务层对底层实现的依赖就越弱。
3.2 仓储实现
仓储实现负责对接真实存储系统，例如关系型数据库、文档数据库或内存结构。它通常会包含数据映射、查询组装、结果转换和异常处理等职责。
3.3 领域对象
领域对象是仓储操作的核心对象，代表业务中的实体、值对象或聚合。仓储并不是为表服务，而是为这些领域概念服务，因此方法设计也应围绕领域语义展开。
3.4 数据映射器
数据映射器用于在领域对象和持久化记录之间转换信息。它可以是独立组件，也可以由 ORM 框架承担一部分工作。其作用是减少对象模型与存储模型之间的直接耦合。
4 常见操作
4.1 创建与保存
创建与保存通常是仓储最基本的职责之一。业务层构造出领域对象后，可通过仓储将其持久化。对于新对象，仓储可能负责分配标识、写入记录并返回保存后的结果。
4.2 按标识查找
按标识查找是最常见的读取方式。仓储根据唯一标识获取对应对象，并在必要时完成关联数据加载、状态重建和缓存更新。由于标识通常稳定，这类操作也最便于优化。
4.3 条件查询
条件查询用于按业务规则筛选对象，例如按状态、时间范围或所属分类检索。良好的仓储会把查询条件表达得尽量清晰，同时避免把过多底层查询语法暴露给上层代码。
4.4 更新与删除
更新用于将对象的最新状态同步到持久化介质，删除则表示移除或标记对象不再可用。在一些系统中，删除并不一定意味着物理清除，也可能采用逻辑删除以保留历史信息。
4.5 分页与排序
当数据量较大时，仓储往往还需提供分页与排序支持。分页可以控制单次返回规模，排序则帮助上层以稳定顺序查看结果。这类能力在列表页面、报表生成和后台检索中较为常见。
5 类型与变体
5.1 泛型仓储
泛型仓储以通用接口覆盖多种对象类型，便于快速复用基础 CRUD 能力。它适合结构相近、规则较简单的场景，但若业务差异较大，过度通用反而会削弱表达力。
5.2 专用仓储
专用仓储针对特定领域对象设计，接口更贴近业务语义。它通常更适合复杂领域模型，因为方法名称和参数能够更准确反映实际业务需求。
5.3 内存仓储
内存仓储将数据保存在程序运行时内存中，常用于演示、原型开发或测试环境。它实现简单、速度快，但进程结束后数据即消失，不能替代真实持久化方案。
5.4 持久化仓储
持久化仓储直接连接数据库、文件系统或其他长期存储介质，是最常见的仓储形态。它不仅要处理读写，还要关注事务、并发、异常恢复和数据一致性。
5.5 只读仓储
只读仓储仅提供查询能力，不承担修改职责。它常见于报表分析、搜索索引或历史数据展示场景，能够将读取与写入路径分离，减少职责混杂。
6 与相关模式的关系
6.1 与 DAO 模式的区别
DAO 模式更偏向数据持久化访问，通常围绕表或记录组织操作；仓储模式则更强调领域对象的集合语义。两者都能用于数据访问抽象，但仓储更适合表达业务概念，DAO 则更贴近存储结构。
6.2 与工厂模式的配合
工厂模式用于创建对象，仓储模式用于管理对象的获取与持久化。二者常配合使用：工厂负责生成符合规则的领域对象，仓储负责将其保存并在需要时重新构造出来。
6.3 与服务层的协作
服务层通常负责编排业务流程，调用仓储获取所需对象，再对对象执行业务操作。仓储不应承载流程控制职责，而应专注于数据访问，以免职责边界模糊。
6.4 与领域服务的边界
领域服务处理那些无法自然归属于某个实体或值对象的业务逻辑，而仓储只负责对象的持久化与检索。若某段逻辑本质上属于业务规则，应放在领域服务中，而不宜塞进仓储。
7 实现细节
7.1 接口设计原则
仓储接口应尽量简洁、稳定，并使用领域术语命名。方法过多会导致接口臃肿，过于底层则会让调用方重新接触技术细节。一般而言，接口应围绕实际业务需要而非数据库能力来设计。
7.2 生命周期管理
仓储对象本身及其依赖资源需要合理管理生命周期。某些场景下，仓储可作为短生命周期对象使用；在另一些场景中，它可能依赖连接池、会话或上下文对象，因此需要与应用框架的生命周期机制配合。
7.3 事务处理
涉及多个写操作时，仓储通常需要与事务机制协同，以保证数据一致性。事务边界一般应由上层服务或应用协调层控制，仓储则负责在该边界内执行具体持久化动作。
7.4 依赖注入集成
仓储模式常与依赖注入结合，以便在运行时注入具体实现。这样，业务代码依赖于抽象接口而非实现类，测试时也更容易替换为模拟对象或内存版本。
8 优点与局限
8.1 优点
8.1.1 降低耦合
仓储将业务逻辑与存储实现分开，使系统各部分之间的依赖关系更清楚。数据库结构调整、存储引擎切换或查询策略变化时，受影响范围通常更可控。
8.1.2 提升可测试性
由于业务层依赖的是接口而非真实数据库，测试时可以注入替身仓储，避免外部环境干扰。这样既能加快测试执行，也便于构造各种边界条件。
8.1.3 改善代码可维护性
当数据访问逻辑集中管理后，重复代码更少，修改路径也更明确。对团队协作而言，仓储还能形成较稳定的约定，减少不同模块各自实现访问逻辑所带来的混乱。
8.2 局限
8.2.1 抽象层增加
仓储引入额外一层抽象，短期内会让代码结构看起来更复杂。对于很小的项目或简单数据访问需求，这种抽象可能不一定划算。
8.2.2 复杂查询处理成本
当查询条件非常复杂时，仓储接口可能变得难以设计，既要保持领域语义，又要兼顾灵活性，往往需要额外的查询对象或规范模式来辅助。
8.2.3 可能引入样板代码
若系统对象很多，仓储接口、实现类、映射逻辑和测试替身都会增加，形成一定的重复性代码。若设计不当，这些样板内容可能抵消部分收益。
9 实践应用
9.1 在面向对象项目中的应用
在普通面向对象项目中，仓储常作为持久化访问层的统一入口。它让业务代码通过对象方法完成数据操作，而不是直接在各处拼接查询语句，从而提升结构一致性。
9.2 在领域驱动设计中的应用
在领域驱动设计中，仓储常用于管理聚合根。外部通常先通过仓储获取聚合，再在聚合内部执行业务变更，最后由仓储保存结果。这种方式有助于维持领域模型的完整性。
9.3 与 ORM 框架结合的实践
仓储经常与 ORM 框架共同使用。ORM 负责对象与表记录之间的映射，仓储则负责从业务角度组织访问方法。两者结合后，开发者既能获得较高的开发效率，也能保留一定的领域抽象。
9.4 测试中的仓储替身
在测试场景中，仓储替身可用于模拟数据来源，例如使用内存集合、伪实现或固定返回值。这样可以独立验证服务层和领域逻辑，而无需依赖真实数据库连接。
10 设计注意事项
10.1 避免过度泛化
仓储接口不宜为了“通用”而牺牲清晰度。若所有对象都共享同一套模糊方法，上层代码往往会失去领域表达力，最终仍需在业务层补回大量判断。
10.2 防止泄露持久化细节
仓储对外应尽量屏蔽表结构、查询语法和存储特性。若调用方需要了解这些底层信息，说明抽象已经过度下沉，可能破坏模式本身的价值。
10.3 处理聚合边界
仓储通常应围绕聚合边界设计，而不是随意跨越对象关系进行读写。聚合外的对象若被直接纳入同一仓储，容易导致一致性规则混乱。
10.4 规避过度依赖查询封装
查询封装固然有助于统一管理，但若所有检索需求都被硬塞进仓储，接口会迅速膨胀。对于特别复杂或高度变化的检索逻辑，适当拆分为专门查询服务往往更合适。