知识卡片
资源库的策略可替换性:切换数据源而不改客户代码
内容
资源库背后的对象来源完全可以不是关系数据库——只要通过特定的策略对象替换掉数据映射的部分实现即可,这对客户代码完全透明。这个特性带来几个实际收益。单元测试提速:单元测试跑起来时可以把资源库背后的策略换成一个纯内存的数据存储——不用真的碰数据库,测试构件(fixture)的搭建也变得简单,无非是构造一些领域对象、扔进一个集合里,而不用真写进数据库、测试结束后再删除,整套长测试包因此能跑得快得多,客户代码本身(依然是构造条件对象、调用matching)完全不用改。多数据源系统同样受益:如果领域对象的来源本就不止关系数据库一种——比如把互联网上的一个XML数据流(也许经由SOAP)当成领域对象的来源,完全可以实现一个专门的策略(比如XMLFeedRepositoryStrategy),从数据流里读取输入、解析成领域对象,客户代码丝毫不需要关心这份数据到底来自数据库表还是一份XML流。此外,对那些一旦加载进内存就不会再变、也不需要重新查询的不可变领域对象,同样可以配一种专门优化过的资源库策略,让它们长期驻留内存、不必反复触发查询。可迁移启发:给一层抽象接口设计”背后策略可替换”这个能力时,真正的收益往往不在生产环境本身,而在于测试效率和面对多种异构数据源时的一致性——能否轻松换成一个纯内存的假实现来跑测试,是检验这层抽象设计得好不好的一个很实用的试金石。
参考来源
- 位置:《企业应用架构模式》第二部分"模式"之"第13章 对象-关系元数据映射模式"之"13.3.1 运行机制""13.3.2 使用时机"(源文件:_epub-src/OEBPS/Text/000150.html、000151.html)
- 结论依据:原文说明"资源库的对象源可能根本不是关系数据库,这样也没问题,资源库能顺利通过特定的策略对象取代数据映射部分……假设有时我们想使用简单的内存数据存储,通常是在为了获得较好性能而想完全在内存中运行单元测试包的时候……一个XMLFeedRepositoryStrategy可能被实现,它从feed中读取输入并从XML中创建领域对象",直接支撑本卡结论。
- 原始内容:没有数据库访问时,许多长的测试包运行得比较快。为单元测试创建固定的构件同样比较简单,如果所做的只是构建一些领域对象并在建立时把它们放置在集合中,而不是保存在数据库中并在析构时删除它们。