从产品展示页面谈谈Hybris系列之二: DTO, Converter和Populator
从产品展示页面谈谈Hybris系列之二: DTO, Converter和Populator
文章作者：张健(Zhang Jonathan)
上一篇文章 从产品展示页面谈谈Hybris的特有概念和设计结构 我们讲解了Hybris一些特有的概念以及大体架构，并且介绍了Facade层里是如何定义DTO(Data Transfer Object)对象。
一个尚未回答的问题: 为什么DTO(在上一篇文章的具体例子里是Java类ProductData)会由Converter来生成?
这篇文章就从此问题开始。
我们再次翻出上一篇文章展示过的这张架构图。
当我们打开一个Hybris应用网页，比如某个Product(产品)的明细页面时, 背后实际上执行了下列的逻辑:
- Service层从数据库里把数据取出，以Model(又称为DAO对象)的形式返回给Facade层。
- Facade层调用Converter, 在Populator的帮助下，基于Model生成了DTO。
- 明细页面的Controller将其对应的JSP路径返回给Hybris框架。
上述步骤完成之后，我们即可看到数据填充完毕之后的Hybris Product明细页面。
本文将详细介绍上述步骤(2), 即DTO的生成逻辑。
DAO
当点击这个名为DSC-H20 BLUE的产品图片后，
可以跳转到它的明细页面。
其中DAO的生成，也就是下图137行代码里的变量productModel的生成逻辑，会在下一篇文章即这个系列的第三篇文章详细阐述。 本文我们重点介绍DTO(第138行变量productData的生成逻辑)。
现在我们可以简单地把DAO对象，即变量productModel理解成它包含了DSC-H20 BLUE这个产品在数据库里存储的明细。
如果有ABAP开发经验的朋友，可以把这个变量包含的内容类比成ABAP里通过OPEN SQL从透明表里取出的数据。 这些数据由于格式原因还不能直接给上层的UI做展示，而需要经过进一步的加工和处理。这些加工由下文的converter和populator来完成。
DTO
之前我们介绍了DTO(productData)是由第138行的convert方法生成的。这个方法的调用者是getProductConverter方法返回的一个Converter的实例，该实例实际上是Spring框架帮我们注入的一个Bean。对Bean这个概念不熟悉的朋友可以用关键字”Spring Bean”在百度或者Google上搜索。
那么ProductConverter这个Bean的Spring相关定义在Hybris项目文件夹的什么地方呢？
- Converter
前一篇文章从产品展示页面谈谈Hybris的特有概念和设计结构介绍过，产品相关的Facade层存在于bin/ext-commerce/commercefacades这个extension。而在其中的resource/commercefacades-spring.xml文件中可以找到productConverter的定义:
第137行到139行表明实际注入的populators属性是一个列表(List)，这个List里的每一个元素是ProductPopulator。 从List这个数据结构我们可以猜想到，Converter主要是通过调用1个或多个Populator来生成DTO对象的。
- Populator
我们再来看看Populator这个接口的代码，它定义了一个名为populate(SOURCE,TARGET)的方法。方法的注释清楚地说明了Populator是用Source变量的字段值去生成(Populate)Target变量的字段值，如下图所示。
回到我们的Product明细页面的展示例子。在ProductPopulator中:
- Source对应Java类ProductModel
- Target对应Java类ProductData
可见, Populator一般用于从Service层的DAO对象生成Facade层的DTO对象。
关于Populator的实际例子, 我们可以看看ProductUrlPopulator这个类, 它是接口Populator的一个具体实现类, 位于package**de.hybris.platform.commercefacades.product.converters.populator**下面。从这个package下面我们也能发现很多其他的Populator，这也解释了本文Converter章节里介绍的为什么Populator属性注入的类型需要选择为List。
从populate方法中可以看到:
- DTO ProductData里的code和name属性的值都是直接取自DAO ProductModel里对应的同名属性；
- DTO ProductData的url属性则是第47行的resolve方法根据DAO ProductModel计算出来的。
这个resolve方法的使用，表明了Populator不只是简单的把DAO对象的值设置到DTO对象中。在Hybris的标准实现里诸如Product url属性这样需要调用其它Service来处理后然后再展示到前端的例子还有很多。
比如商品的库存，多货币价格等信息, 在数据库端本来就没有和产品信息存在同一张表，自然也不能直接从Product的DAO对象中获取，而是需要在相关的Populator里调用单独的物流处理和价格处理的Service来生成。
这里我们再回想下Hybris的三层结构图。
设想下如果没有Facade层和DTO对象，前端的Controller将不得不调用很多Service，返回很多单独的Model（如产品，物流和价格信息）给页面，加重页面处理的负担。而Hybris的Facade层包装了Service层的复杂逻辑，为前端提供了简明统一的DTO对象，大大降低了前端的处理复杂度。这正是面向对象设计模式中的Facade（外观）模式的体现，因此我们能够从Hybris的架构图中发现Facade层的名字。
希望大家通过这篇文章对Hybris Facade层的Converter和Populator能有比较详细的了解。下一篇我们将继续介绍Hybris的Service层。
Jerry注:
优秀的产品总是有着相似的设计思路。本文介绍的DAO和DTO, 不仅仅出现在Hybris里，在SAP的很多其他产品里也有用到。
在SAP CRM里，从ABAP数据库里取出的数据因为结构差异无法直接被SAP CRM的BSP UI消费，必须要在图中的Generic Interaction Layer里做一个结构和格式的转换:
下图是SAP CRM UI上产品长文本字段的一个截图:
这个长文本字段的值, 从数据库取出到最后显示在UI上，也经历了在Populator(下图的ABAP类: CL_CRM_PRODIL_LONGTEXT)里从DAO到DTO的转换。
至此我们能发现无论是在SAP Hybris还是SAP CRM里，这种DAO到DTO的映射都体现在具体的代码里。
而在SAP Business by Design, SAP Hybris Cloud for Customer和SAP S/4HANA里，这种DAO到DTO的映射关系则维护在一些模型里。这样, 应用开发人员负责维护映射关系，而框架负责统一处理映射关系。即使将来因为业务变化导致这些映射关系也需要发生变化，此时可以仅修改维护映射关系的模型，而无需修改任何代码。
SAP把底层模型层(Model Layer)和上层消费层(Consumption Layer)之间的存储及解析映射关系模型的这一中间层称为SADL(Service Adaptation Definition Layer, L在有的上下文里也称为Language)。维护映射关系的模型则成为SADL模型。如下图所示:
在这个系列的下一篇文章里，Jonathan将介绍Hybris Commerce的持久层设计原理。