Hybris Enterprise Commerce Platform 服务层的设计与实现
Hybris Enterprise Commerce Platform 服务层的设计与实现
版权声明：本文为博主汪子熙原创文章，未经博主允许不得转载。 https://cloud.tencent.com/developer/article/1440906
Hybris Enterprise Commerce Platform这个系列之前已经由我的同事，SAP成都研究院Hybris开发团队的同事张健(Zhang Jonathan)发布过两篇文章了。这里Jerry要特别感谢张健，尽管最近他的第二个孩子诞生了，工作之余的生活变得更加忙碌，然而张健仍然抽出少的可怜的业余时间完成了这个系列的第三篇文章。
前两篇文章分别介绍了SAP Hybris的前端和DTO层：
- 从产品展示页面谈谈Hybris的特有概念和设计结构
- 从产品展示页面谈谈Hybris系列之二: DTO, Converter和Populator
本文由张健继续向我们介绍SAP Hybris的持久层即Service层。下面是他的正文。
前两篇文章分别介绍了SAP Hybris的前端和DTO层：
- 从产品展示页面谈谈Hybris的特有概念和设计结构
- 从产品展示页面谈谈Hybris系列之二: DTO, Converter和Populator
当我们打开Hybris某个Product的明细页面时，Hybris后台执行了下面三步逻辑：
- Service层从数据库里把数据取出，以Model(又称为DAO对象)的形式返回给Facade层。
- Facade层调用Converter, 在Populator的帮助下，基于Model生成了DTO。
- Product明细页面的Controller将其对应的JSP视图路径返回给Hybris框架，通过JSP技术绘制出最后的UI。
其中步骤2和3已经在这个系列前两篇文章介绍过，本文将详细介绍上述步骤1。
Service层用XML定义的形式来管理Hybris的类型系统，既建立起与数据库表的关联，又将类型系统与具体的数据库实现进行了隔离。Service层的ModelService和Flexible Search提供了便捷的增删改查功能。让我们来一一了解。
Hybris类型系统
在DTO层的ProductFacade里，调用了Service层中获取ProductModel的方法如下。
很简单的几句代码，和其他常见的Java Web项目的Service很相似。那么ProductModel是需要开发人员自行创建吗？
应当注意ProductModel这样的POJO类(Plain Old Java Object)不需开发人员自行创建，而是通过Hybris自有的类型系统生成的。
Hybris里的类型分为两类，第一类是包含所有Hybris业务相关类型的ItemType（又称ComposedType），Product即是这种类型。第二类是为ItemType的集合属性和关系属性提供支持的DataType, 包括了 CollectionTypes, MapTypes, EnumerationTypes, RelationTypes 和 AtomicTypes。例如产品对应的多个媒体文件，就可以用CollectionTypes来定义，然后再用RelationTypes和Product类型做关联。
ABAP顾问们可以把前者（ItemType）类比成ABAP Data Dictionary里定义的包含了业务逻辑的全局数据类型，而后者就是ABAP里用STANDARD, SORTED和HASHED TABLE等等将这些业务数据类型的一个聚合。而对于Java开发者来说， CollectionTypes, MapTypes这些类型其实就是Hybris对JDK中的List, Map等类型一个更高层次的抽象。
items.xml
和Hibernate框架使用XML定义类型和数据库配置相似，Hybris类型系统的具体定义存在各个extension的items.xml文件里。比如Product类型是存在于”../hybris/bin/platform/ext/core/resources”文件夹下的core-items.xml文件内。这个文件也定义了很多Hybris核心的业务类型。
我们看一个实际的例子，即Product类型在items.xml中的定义。SAP Hybris的帮助文档里有items.xml里每个字段的详细含义，这里只介绍下图中红色高亮的字段。
extends: GenericItem。表明Product这个类型是在另一个类型GenericItem基础上做扩展。
GenericItem是根类型，相当于Java类型系统的java.lang.Object。Hybris类型系统通过继承的方式避免了字段的重复建模。
假设我们已经用上面展示的items.xml进行了Product的建模，现在有一个新的需求，定义CustomerProduct类型。从业务上说，CustomerProduct仅仅是在Product类型的基础上增加一个字段用于维护Customer ID。ABAP顾问们会新建一个CustomerProduct的结构，把Product类型通过Include的方式添加到CustomerProduct中去，通过include的方式继承前者上维护的所有字段，然后只需在CustomerProduct上定义一个新字段CUSTOMER_ID即可。
对于Hybris类型系统，思路类似，用CustomerProduct类型去extends Product类型，然后只需定义一个CustomerID字段即可。
autocreate = true: 在执行Hybris命令行ant initialize进行Hybris系统初始化时，根据items.xml的定义在数据库表中创建对应的类型。
generate = true: 在ant编译时生成该类型对应的POJO类。
以上图的Product类型为例，因为generate属性设置为true, 因此编译之后，我们能在下面的文件夹发现一个自动生成的POJO类，命名规范为<类型名称>Model.java:
hybrisinplatformootstrapgensrcdehybrisplatformcoremodelproduct
和ABAP很多自动生成的资源通常都放在名为$GEN之类的包的套路一样，POJO类所在的文件目录中的gensrc，也提示了该文件是自动生成的。
打开ProductModel.java查看其内容，能进一步了解items.xml里定义的属性是如何映射到这个自动生成的POJO类的：items.xml里定义的每一个类型属性，都会在POJO类里自动生成一套set和get方法。
以name属性为例，在ProductModel.java里自动生成的setName和getName：
table = Products: 数据库对应的表名，在整个Hybris类型系统唯一存在。
attribute autocreate=”true” qualifier=”code” type=”java.lang.String” generate=”true”：POLO类中会出现一个新的成员，名称为code，类型为String，并带有set和get方法，ant initialize时在数据库表中创建该属性。
ModelService
定义好类型后，就需要开发相应的增删改查功能了。Hybris提供了de.hybris.platform.servicelayer.model.ModelService类作为帮助类，只需传入POJO类给对应方法，即可实现增删改查功能。这和Hibernate里的帮助类的用法是类似的。查询操作对应get方法，创建和更新对应save方法，删除操作则为remove方法。还有saveAll和removeAll方法，只需传入业务类型的集合即可实现批量增改或删除。
下图是一个例子，通过getModelService拿到ModelService实例，执行save操作。
Flexible Search
对于复杂查询，Hybris也提供了自己的查询语句Flexsible Search。如ProductDao中使用的关联Category类型的查询：
用过ADBC和JDBC的ABAP顾问和Java开发者，对上面的代码一定不会陌生。
下面是从Jerry的博客里摘出来的一张图，ADBC和JDBC的对比：
https://blogs.sap.com/2017/05/08/adbc-and-jdbc/
Hybris支持主流数据库，包括MySQL,Oracle,SQL Server及SAP HANA数据库等等。而Flexible Search概念的引入，思路类似ABAP Open SQL，通过编写不依赖于任何具体数据库提供商的Flexible Search代码，将Hybris应用层同底层数据库的具体实现做了解耦。而上面的语句中，POJO类里如ProductModel._TYPECODE 的值就是“Product”，是编译时自动生成的。因此查询语句可转译成如下文本：
问号后面的”Category“是要传入查询语句的参数名，这里即为传入了方法的参数“CategoryModel”。
到这里Hybris的Service层就基本介绍完了，而Hybris概要的系列文章也告一段落。希望大家通过这些文章对Hybris Enterprise Commerce Platform有一定的认识。感谢阅读。
