年前總結一下這兩個星期在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大致如下（還有很多其他內容，這裡只寫重點）

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就能夠專注於處理其他更重要的操作。（因為地方實在沒有了，我略去了一直沒變的幾部分）