年前總結一下這兩個星期在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就能夠專注於處理其他更重要的操作。（因爲地方實在沒有了，我略去了一直沒變的幾部分）
轉自:https://blog.csdn.net/qq_38796309/article/details/79272198