本篇文章给大家分享的是有关Hybris Enterprise Commerce Platform 服务层的设计与实现是怎样的，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。
我们来介绍SAP Hybris的持久层即Service层。
当我们打开Hybris某个Product的明细页面时，Hybris后台执行了下面三步逻辑：
1. Service层从数据库里把数据取出，以Model(又称为DAO对象)的形式返回给Facade层。
2. Facade层调用Converter, 在Populator的帮助下，基于Model生成了DTO。
3. Product明细页面的Controller将其对应的JSP视图路径返回给Hybris框架，通过JSP技术绘制出最后的UI。
其中步骤2和3已经在这个系列前两篇文章介绍过，本文将详细介绍上述步骤1。
Service层用XML定义的形式来管理Hybris的类型系统，既建立起与数据库表的关联，又将类型系统与具体的数据库实现进行了隔离。Service层的ModelService和Flexible Search提供了便捷的增删改查功能。让我们来一一了解。
在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等类型一个更高层次的抽象。
和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时在数据库表中创建该属性。
定义好类型后，就需要开发相应的增删改查功能了。Hybris提供了de.hybris.platform.servicelayer.model.ModelService类作为帮助类，只需传入POJO类给对应方法，即可实现增删改查功能。这和Hibernate里的帮助类的用法是类似的。查询操作对应get方法，创建和更新对应save方法，删除操作则为remove方法。还有saveAll和removeAll方法，只需传入业务类型的集合即可实现批量增改或删除。
下图是一个例子，通过getModelService拿到ModelService实例，执行save操作。
对于复杂查询，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 Enterprise Commerce Platform 服务层的设计与实现是怎样的，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注亿速云行业资讯频道。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
