Hybris Enterprise Commerce Platform 服務層的設計與實現
Hybris Enterprise Commerce Platform這個系列之前已經由我的同事，SAP成都研究院Hybris開發團隊的同事張健(Zhang Jonathan)發布過兩篇文章了。這裏Jerry要特別感謝張健，盡管最近他的第二個孩子誕生了，工作之余的生活變得更加忙碌，然而張健仍然抽出少的可憐的業余時間完成了這個系列的第三篇文章。
前兩篇文章分別介紹了SAP Hybris的前端和DTO層：
從產品展示頁面談談Hybris的特有概念和設計結構
從產品展示頁面談談Hybris系列之二: DTO, Converter和Populator
本文由張健繼續向我們介紹SAP Hybris的持久層即Service層。下面是他的正文。
前兩篇文章分別介紹了SAP Hybris的前端和DTO層：
- 從產品展示頁面談談Hybris的特有概念和設計結構
- 從產品展示頁面談談Hybris系列之二: DTO, Converter和Populator
當我們打開Hybris某個Product的明細頁面時，Hybris後臺執行了下面三步邏輯：
1. Service層從數據庫裏把數據取出，以Model(又稱為DAO對象)的形式返回給Facade層。
2. Facade層調用Converter, 在Populator的幫助下，基於Model生成了DTO。
3. Product明細頁面的Controller將其對應的JSP視圖路徑返回給Hybris框架，通過JSP技術繪制出最後的UI。
其中步驟2和3已經在這個系列前兩篇文章介紹過，本文將詳細介紹上述步驟1。
Service層用XML定義的形式來管理Hybris的類型系統，既建立起與數據庫表的關聯，又將類型系統與具體的數據庫實現進行了隔離。Service層的ModelService和Flexible Search提供了便捷的增刪改查功能。讓我們來一一了解。
Hybris類型系統
在DTO層的ProductFacade裏，調用了Service層中獲取ProductModel的方法如下。
很簡單的幾句代碼，和其他常見的Java Web項目的Service很相似。那麽ProductModel是需要開發人員自行創建嗎？
應當註意ProductModel這樣的POJO類(Plain Old Java Object)不需開發人員自行創建，而是通過Hybris自有的類型系統生成的。
Hybris裏的類型分為兩類，第一類是包含所有Hybris業務相關類型的ItemType（又稱ComposedType），Product即是這種類型。第二類是為ItemType的集合屬性和關系屬性提供支持的DataType, 包括了 CollectionTypes, MapTypes, EnumerationTypes, RelationTypes 和 AtomicTypes。例如產品對應的多個媒體文件，就可以用CollectionTypes來定義，然後再用RelationTypes和Product類型做關聯。
ABAP顧問們可以把前者（ItemType）類比成ABAP Data Dictionary裏定義的包含了業務邏輯的全局數據類型，而後者就是ABAP裏用STANDARD, SORTED和HASHED TABLE等等將這些業務數據類型的一個聚合。而對於Java開發者來說， CollectionTypes, MapTypes這些類型其實就是Hybris對JDK中的List, Map等類型一個更高層次的抽象。
items.xml
和Hibernate框架使用XML定義類型和數據庫配置相似，Hybris類型系統的具體定義存在各個extension的items.xml文件裏。比如Product類型是存在於"../hybris/bin/platform/ext/core/resources"文件夾下的core-items.xml文件內。這個文件也定義了很多Hybris核心的業務類型。
我們看一個實際的例子，即Product類型在items.xml中的定義。SAP Hybris的幫助文檔裏有items.xml裏每個字段的詳細含義，這裏只介紹下圖中紅色高亮的字段。
extends: GenericItem。表明Product這個類型是在另一個類型GenericItem基礎上做擴展。
GenericItem是根類型，相當於Java類型系統的java.lang.Object。Hybris類型系統通過繼承的方式避免了字段的重復建模。
假設我們已經用上面展示的items.xml進行了Product的建模，現在有一個新的需求，定義CustomerProduct類型。從業務上說，CustomerProduct僅僅是在Product類型的基礎上增加一個字段用於維護Customer ID。ABAP顧問們會新建一個CustomerProduct的結構，把Product類型通過Include的方式添加到CustomerProduct中去，通過include的方式繼承前者上維護的所有字段，然後只需在CustomerProduct上定義一個新字段CUSTOMER_ID即可。
對於Hybris類型系統，思路類似，用CustomerProduct類型去extends Product類型，然後只需定義一個CustomerID字段即可。
autocreate = true: 在執行Hybris命令行ant initialize進行Hybris系統初始化時，根據items.xml的定義在數據庫表中創建對應的類型。
generate = true: 在ant編譯時生成該類型對應的POJO類。
以上圖的Product類型為例，因為generate屬性設置為true, 因此編譯之後，我們能在下面的文件夾發現一個自動生成的POJO類，命名規範為<類型名稱>Model.java:
hybrisinplatformootstrapgensrcdehybrisplatformcoremodelproduct
和ABAP很多自動生成的資源通常都放在名為$GEN之類的包的套路一樣，POJO類所在的文件目錄中的gensrc，也提示了該文件是自動生成的。
打開ProductModel.java查看其內容，能進一步了解items.xml裏定義的屬性是如何映射到這個自動生成的POJO類的：items.xml裏定義的每一個類型屬性，都會在POJO類裏自動生成一套set和get方法。
以name屬性為例，在ProductModel.java裏自動生成的setName和getName：
table = Products: 數據庫對應的表名，在整個Hybris類型系統唯一存在。
attribute autocreate="true" qualifier="code" type="java.lang.String" generate="true"：POLO類中會出現一個新的成員，名稱為code，類型為String，並帶有set和get方法，ant initialize時在數據庫表中創建該屬性。
ModelService
定義好類型後，就需要開發相應的增刪改查功能了。Hybris提供了de.hybris.platform.servicelayer.model.ModelService類作為幫助類，只需傳入POJO類給對應方法，即可實現增刪改查功能。這和Hibernate裏的幫助類的用法是類似的。查詢操作對應get方法，創建和更新對應save方法，刪除操作則為remove方法。還有saveAll和removeAll方法，只需傳入業務類型的集合即可實現批量增改或刪除。
下圖是一個例子，通過getModelService拿到ModelService實例，執行save操作。
Flexible Search
對於復雜查詢，Hybris也提供了自己的查詢語句Flexsible Search。如ProductDao中使用的關聯Category類型的查詢：
用過ADBC和JDBC的ABAP顧問和Java開發者，對上面的代碼一定不會陌生。
下面是從Jerry的博客裏摘出來的一張圖，ADBC和JDBC的對比：
https://blogs.sap.com/2017/05/08/adbc-and-jdbc/
Hybris支持主流數據庫，包括MySQL,Oracle,SQL Server及SAP HANA數據庫等等。而Flexible Search概念的引入，思路類似ABAP Open SQL，通過編寫不依賴於任何具體數據庫提供商的Flexible Search代碼，將Hybris應用層同底層數據庫的具體實現做了解耦。而上面的語句中，POJO類裏如ProductModel._TYPECODE 的值就是“Product”，是編譯時自動生成的。因此查詢語句可轉譯成如下文本：
問號後面的”Category“是要傳入查詢語句的參數名，這裏即為傳入了方法的參數“CategoryModel”。
到這裏Hybris的Service層就基本介紹完了，而Hybris概要的系列文章也告一段落。希望大家通過這些文章對Hybris Enterprise Commerce Platform有一定的認識。感謝閱讀。
要獲取更多Jerry的原創技術文章，請關註公眾號"汪子熙"或者掃描下面二維碼:
Hybris Enterprise Commerce Platform 服務層的設計與實現