HybrisEnterpriseCommercePlatform服务层的设计与实现是怎样的
本篇文章给大家分享的是有关Hybris Enterprise Commerce Platform 服务层的设计与实现是怎样的,小编觉得挺实用的,因此分享给大家学习,希望大家阅读完这篇文章后可以有所收获,话不多说,跟着小编一起来看看吧。
创新互联公司专注于企业营销型网站、网站重做改版、铁岭网站定制设计、自适应品牌网站建设、H5响应式网站、成都商城网站开发、集团公司官网建设、成都外贸网站建设公司、高端网站制作、响应式网页设计等建站业务,价格优惠性价比高,为铁岭等各大城市提供网站开发制作服务。
我们来介绍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提供了便捷的增删改查功能。让我们来一一了解。
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 Enterprise Commerce Platform 服务层的设计与实现是怎样的,小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注创新互联行业资讯频道。
网页标题:HybrisEnterpriseCommercePlatform服务层的设计与实现是怎样的
标题来源:http://ybzwz.com/article/pooose.html