知识卡片
双向映射的两步策略:应对同一数据的多物理存储
内容
有时同样的数据需要从不止一种数据源里取出来——可能是多个数据库因为复制粘贴式复用而在方案上有细微差别(差别越多,处理起来越头疼),也可能是要把同类数据同时从XML消息、CICS事务和关系表中抽取出来。最直接的做法是给每个数据源各建一套独立的映射层,但如果这些数据源本质上高度相似,这样做会导致大量重复代码。更好的办法是两步映射:第一步把数据从内存对象方案转化成一个”逻辑数据存储方案”——这个中间方案专门设计来最大化各个物理数据源格式之间的相似之处;第二步再把这个逻辑数据存储方案映射到具体的物理存储方案,把各个物理数据源之间真正的差异隔离在这一步里处理。这种额外的中间层只有在”数据源之间共性多、但又有几个让人头疼的差异点”时才划算——差异越大,中间层带来的收益越能覆盖它自身的复杂度。可以把从逻辑数据存储到物理数据存储这一步本身也看作一个入口,再用任意合适的映射技术从应用程序逻辑映射到逻辑数据存储层。可迁移启发:当同一份业务数据要对接多个”形态相似但细节有出入”的外部系统时,与其对每个外部系统各写一套完整映射,不如先抽出一层体现共性的中间表示,把差异隔离到最后一步——这个思路不局限于数据库场景,同样适用于多渠道消息格式、多供应商API适配等场景。
参考来源
- 位置:《企业应用架构模式》第一部分"表述"之"第3章 映射到关系数据库"之"3.5 建立映射"(源文件:_epub-src/OEBPS/Text/000022.html)
- 结论依据:原文说明"在这种情况下,可以考虑两步映射策略。第一步把数据从内存方案中转化到逻辑数据存储方案。设计逻辑数据存储方案是用来最大化数据源格式中的相似之处。第二步映射从逻辑数据存储方案到实际物理存储方案。第二步包含区别……当有许多共同点时,额外的步骤仅仅补偿它们自身,因此你应该在有相似但又有十分头疼的不同的物理数据存储时使用它",直接支撑本卡结论。
- 原始内容:最简单的选择是建立多个映射层,每个数据源一个。然而,如果数据非常类似的话,就会导致过多的复制。在这种情况下,可以考虑两步映射策略。