| name | metaframe-data-mapper-pattern |
|---|---|
| category | engineering |
| description | 数据映射器模式 | Code & Engineering |
英文名: Data Mapper Pattern
分类: 编码实践
作者: Martin Fowler, 2002
复杂度: advanced
成熟度: foundational
AI 相关: ❌ 否
在内存对象与数据库之间传输数据，同时保持两者相互独立，领域对象对持久化完全无知
- 持久化无知：领域对象对数据库一无所知——没有 SQL、没有注解、没有 ORM 基类——使其成为业务规则的纯粹表达
- 双向转换：映射器读取行并构造领域对象（水合），以及读取领域对象生成 SQL（脱水），保持两侧整洁
- 阻抗不匹配解决：映射器桥接关系世界（表、连接、外键）与对象世界（继承、关联、值对象）之间的结构差异
- 设计持久化无知的领域对象：使用仅包含业务逻辑和内存状态的领域类，没有数据库注解、基类继承或 SQL 意识
- 创建映射器类：实现专用类（或 ORM 映射配置），负责 SELECT、INSERT、UPDATE、DELETE 以及在数据库行和领域对象之间进行转换
- 将列映射到字段：定义从表列到对象属性的显式映射，处理类型转换、命名差异和值对象组合
- 处理标识和懒加载：映射器管理对象标识（避免同一行在内存中有重复实例），并可通过代理支持关联的懒加载
- 与工作单元集成：将加载的和变更的对象注册到工作单元，使映射器的写操作在提交时批处理到单一事务中
['领域对象很复杂，其结构与关系模式显著不同（阻抗不匹配）', '领域对象必须保持对持久化关注点的自由，以便在非数据库上下文中测试、序列化或重用', '数据库模式是遗留的或独立拥有的，无法更改以匹配对象模型']
- 保持领域类没有任何持久化注解或基类要求——纯 POJO/POCO 实现最高程度的可测试性
- 独立对映射配置进行版本控制和测试，在模式迁移回归到达生产环境之前捕获它们
- 考虑对读模型使用带显式 SQL 的微型 ORM，在完整数据映射器开销不必要的地方
- 不要让映射器渗入领域层——映射关注点（RowMapper、ResultSetExtractor）专属于基础设施层
- 不要将数据映射器用于简单的、每类一表的 CRUD 实体，活动记录以更少的繁文缛节提供相同的隔离
- 当成熟的 ORM 涵盖你的模式时，不要手写映射器——手动映射器需要大量精力来维护模式变更
Sources: SDFrame (Software Design) MetaFrame: 💻 Code & Engineering / 编码与工程