Hybris阶段总结hybris架构
Posted shaun-sheng
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Hybris阶段总结hybris架构相关的知识,希望对你有一定的参考价值。
年前总结一下这两个星期在SAP实习学到的一些东西
先上图:
从底往上总结,之后会有个小例子来解释一下
1、Persistence layer
就是作为hybris所连接的数据库这一层,其中hybris支持连接mysql、oracle、sqlserver和SAP自己的HANA。但是因为hybris本身设计的原因(下一条详述),我们并不需要对数据库进行直接的操作。
2、Item
准确的说并不是作为一个层,而是一种数据类型,在每个extension项目中的xxxx-item.xml中定义(之后的博文会详述,简单的说extension就是针对hybris中各层我们自己定义的,需要满足个性化需求的拓展,导入eclipse后会以一个个java project形式存在)。
可以说item是开发者能够接触到的最接近底层的东西。在item里我们使用统一的xml语言来对每种数据以及数据之间的关系进行定义,比如我们需要一个ContactRequest对象,其中有message属性,那么我们定义如下
-
<itemtype 在这里会定义很多配置属性>
-
<attributes>
-
<attribute qualifier="message" type="java.lang.String">
-
<persistence type="property"/>
-
</attribute>
-
</attributes>
-
</itemtype>
我就直接将其理解为hybris自己能够理解的数据库定义方法,在你将其定义好以后,在系统build的过程中(hybris使用的是ant),hybris会根据不同的数据库方言,使用ORM等(这个之后我还要详细查查)自动在数据库中进行建表。
3、Service
service指的是很细粒度的、商务上所需要的各种方法,,比如计算总价、对数据库进行的CRUD等。在hybris已有的系统中我们会找到非常多类型的hybris接口定义。service层将数据整理好以后,会以model的形式暴露给fa?ade层来使用,不同的service之间也通过model来传递数据。
4、Model
Model是java类,与我们在item中定义的各种数据一一对应,但是我们并不需要对其进行逐个编写,它会在hybris 进行build期间自动的生成于platform里的gensrc文件夹中。之所以将不同的extension定义的item生成的model集中在同一个文件夹下,是因为不同model之间可能会存在互相包含关系,这样model生成过程中如果生成一个model时里面包含的其他extension的model class,在extension各自生成自己的model并放在自己文件夹的情况下,就会发现有未定义的class,进而导致build failure。
之前定义的item所对应的model大致如下(还有很多其他内容,这里只写重点)
[java] view plain copy
- <code class="language-html">public class ContactRequestModel extends ItemModel
- {
- public final static String _TYPECODE = "ContactRequest";
- private String _message;
- public String getMessage()
- {
- //message的get方法
- }
- public void setMessage(final String value)
- {
- //message的set方法
- }
- }</code>
5、DAO
DAO,全称Data Access Obiect是我们自己需要编写的一系列Java类,在hybris已有的系统中只有接口定义。其作用就是在service需要对数据库进行类似于CRUD的操作时,就会调用DAO来进行,DAO会返回model来供service的使用。
6、Fa?ade
这一层中fa?ade也是以各种java类存在,在hybris中也有巨量的接口可以去调用。在这一层中会定义一系列比较偏向“业务”方面的方法,更加粗粒度,比如向购物城中添加商品、搜索商品等,facade接收service传过来的model,进行处理以后回以DTO(datatransfer object)的形式上传到client层。
7、DTO
这是用于数据传输的POJO(plain old java object,不是JavaBean,EntityBean 或者SessionBean。 POJO不担当任何特殊的角色,也不实现任何特殊的Java框架的接口),完全由你自己定义。
DTO只用于传输数据,里面除了保存数据的各种数据类型以外就只有相对应的get与set方法。使用DTO你可以将多个不同extension中所生成的多个不同的model中的数据整合到一起,这样会避免只是用model所带来的各种潜在问题。
8、为何使用fa?ade与DTO(摘自hybris使用手册)
之所以需要DTO,是因为在某些情况下,仅仅使用service来处理model并传给上层client的话,service类会变得很笨重:(1)我们需要更加简洁的数据格式来传递数据给client层的JSP来进行展示;(2)当我们需要将一堆对象序列化来传输给其他系统的时候;(3)当我们需要对不同用户权限进行相应限制的时候。因此我们需要一个比model更加简化的数据表示方式,而这就是DTO。
还有一个原因就是,不同的进程间进行通信时,通常会是调用远程接口情况,比如说web service,因此每一次请求都会耗时包括:请求传输时间、远端处理时间、返回结果传输时间。这其中将请求传送出去以及结果传输回来的时间会占很大比重(IO传输时间远大于系统内部处理时间)。因此如果将多次请求内容放在一个DTO中,则可以大大减少传输信息的时间,提高系统吞吐率。
需要fa?ade,首先是因为我们需要生成DTO的方法与方法所在的类。并且,fa?ade相当于为controller提供了一组更加简洁的操作,因为service层中操作粒度过细,并且还不提供权限控制等操作,因此fa?ade相当于一个虚拟的中间件,从下层(service)中调用各种偏向底层的方法,自己对方法进行排列组合、加上自己的处理以后,对不同使用者暴露不同的方法与数据的调用。
9、Converter
这是fa?ade所调用的一种java类,作用就是将model转化为DTO。
10、Client层
前端所包括的一系列东西,包括但不限于MVC中的controller、web service或是个脚本。
11、在以上所有的架构中,只有service、item、client是必须出现的,其他所有功能都是可选项
下面以一个例子来进行说明:
PS.一下所有图中都没有体现自动生成的model(每次还要多画两个对象,好烦。。。),但是有的对象中会有xxxxmodel
又PS. 因为Hybris整体采用Spring架构,所以除了编程以外还会有很多的.xml文件相关的操作,这里省略,之注重对象之间的关系
1、比如说你作为一个在SAP的实习生,现在需要使用hybris开发一个功能:在前端查询商品信息。
其中由ProductModel体现,储存商品基本信息(注意这是个model);而ProductModel中又包含PriceModel(这也是个model),储存币种与币值。
那么你三两下就搞出了一个只有最基本功能的结构:
其中ProductController就是你在前端页面中作用到的controller(hybris会使用Spring MVC架构)。Controller会调用两个service来分别获取商品信息与价格信息,之后会调用handleRequest操作来呈现信息。
2、 当然我们为了将service与数据库进行解耦,会引入DAO,它会专门负责数据相关的CRUD之类的操作,改了之后变成了这样:
这样service就能专注于对于model的操作(当然在这个例子里体现不太出来),而将繁琐的数据读写等操作交给了DAO来完成。
3、之后我们想到,controller直接调用service也不好,考虑到上面第8点所提到的各种情况,使用fa?ade能够体现出更加良好的代码结构与可扩展性,于是我们继续改,成果是这样:
其中fa?ade代替了service来与controller进行通信,并且调用service来获取所需要的model并转化为controller所需要的DTO(图中的ProductData与PriceData)
4、最后,我们创建converter来专门处理fa?ade中的model转化为controller的任务,这样fa?ade就能够专注于处理其他更重要的操作。(因为地方实在没有了,我略去了一直没变的几部分)
以上是关于Hybris阶段总结hybris架构的主要内容,如果未能解决你的问题,请参考以下文章
如何自定义 pcm 后台以过滤 Hybris 中的超类别搜索结果