Hybris架构总结。。。。个人笔记

发布时间：2018-07-23 16:30,

浏览次数：214

, 标签：

Hybris

先上图：

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属性，那么我们定义如下

type="java.lang.String">

我就直接将其理解为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)，储存币种与币值。

那么你三两下就搞出了一个只有最基本功能的结构：

其中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就能够专注于处理其他更重要的操作。(因为地方实在没有了，我略去了一直没变的几部分)