Hybris阶段总结（2）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属性，那么我们定义如下

1. <itemtype 在这里会定义很多配置属性>

2. <attributes>

3. <attribute qualifier="message" type="java.lang.String">

4. <persistence type="property"/>

5. </attribute>

6. </attributes>

7. </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

1. <code class="language-html">public class ContactRequestModel extends ItemModel
2. {
3. public final static String _TYPECODE = "ContactRequest";
4. private String _message;
5. public String getMessage()
6. {
7. //message的get方法
8. }
9. public void setMessage(final String value)
10. {
11. //message的set方法
12. }
13. }</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就能够专注于处理其他更重要的操作。（因为地方实在没有了，我略去了一直没变的几部分）

​

转自:https://blog.csdn.net/qq_38796309/article/details/79272198