Hybris阶段总结(2)hybris架构

年前总结一下这两个星期在SAP实习学到的一些东西

先上图:

Hybris阶段总结(2)hybris架构_第1张图片
从底往上总结,之后会有个小例子来解释一下
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属性,那么我们定义如下

    
      
        
      
    

 我就直接将其理解为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 大致如下(还有很多其他内容,这里只写重点)
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方法
	}
}


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),储存币种与币值。

 那么你三两下就搞出了一个只有最基本功能的结构:
Hybris阶段总结(2)hybris架构_第2张图片
 其中ProductController就是你在前端页面中作用到的controller(hybris会使用Spring MVC架构)。Controller会调用两个service来分别获取商品信息与价格信息,之后会调用handleRequest操作来呈现信息。

2、 当然我们为了将service与数据库进行解耦,会引入DAO,它会专门负责数据相关的CRUD之类的操作,改了之后变成了这样:
Hybris阶段总结(2)hybris架构_第3张图片

 这样service就能专注于对于model的操作(当然在这个例子里体现不太出来),而将繁琐的数据读写等操作交给了DAO来完成。


3、之后我们想到,controller直接调用service也不好,考虑到上面第8点所提到的各种情况,使用façade能够体现出更加良好的代码结构与可扩展性,于是我们继续改,成果是这样:
Hybris阶段总结(2)hybris架构_第4张图片

 其中façade代替了service来与controller进行通信,并且调用service来获取所需要的model并转化为controller所需要的DTO(图中的ProductData与PriceData)

 

4、最后,我们创建converter来专门处理façade中的model转化为controller的任务,这样façade就能够专注于处理其他更重要的操作。(因为地方实在没有了,我略去了一直没变的几部分)

Hybris阶段总结(2)hybris架构_第5张图片

 

 

你可能感兴趣的:(hybris)