文章作者：張健(Zhang Jonathan)

上一篇文章?從產品展示頁面談談Hybris的特有概念和設計結構?我們講解了Hybris一些特有的概念以及大體架構，并且介紹了Facade層里是如何定義DTO(Data Transfer Object)對象。

一個尚未回答的問題: 為什么DTO(在上一篇文章的具體例子里是Java類ProductData)會由Converter來生成?

這篇文章就從此問題開始。

我們再次翻出上一篇文章展示過的這張架構圖。

當我們打開一個Hybris應用網頁，比如某個Product(產品)的明細頁面時, 背后實際上執行了下列的邏輯:

Service層從數據庫里把數據取出，以Model(又稱為DAO對象)的形式返回給Facade層。

Facade層調用Converter, 在Populator的幫助下，基于Model生成了DTO。

明細頁面的Controller將其對應的JSP路徑返回給Hybris框架。

上述步驟完成之后，我們即可看到數據填充完畢之后的Hybris Product明細頁面。

本文將詳細介紹上述步驟(2), 即DTO的生成邏輯。

DAO

當點擊這個名為DSC-H20 BLUE的產品圖片后，

可以跳轉到它的明細頁面。

其中DAO的生成，也就是下圖137行代碼里的變量productModel的生成邏輯，會在下一篇文章即這個系列的第三篇文章詳細闡述。 本文我們重點介紹DTO(第138行變量productData的生成邏輯)。

現在我們可以簡單地把DAO對象，即變量productModel理解成它包含了DSC-H20 BLUE這個產品在數據庫里存儲的明細。

如果有ABAP開發經驗的朋友，可以把這個變量包含的內容類比成ABAP里通過OPEN SQL從透明表里取出的數據。 這些數據由于格式原因還不能直接給上層的UI做展示，而需要經過進一步的加工和處理。這些加工由下文的converter和populator來完成。

DTO

之前我們介紹了DTO(productData)是由第138行的convert方法生成的。這個方法的調用者是getProductConverter方法返回的一個Converter的實例，該實例實際上是Spring框架幫我們注入的一個Bean。對Bean這個概念不熟悉的朋友可以用關鍵字”Spring Bean”在百度或者Google上搜索。

那么ProductConverter這個Bean的Spring相關定義在Hybris項目文件夾的什么地方呢？

Converter

前一篇文章從產品展示頁面談談Hybris的特有概念和設計結構介紹過，產品相關的Facade層存在于bin/ext-commerce/commercefacades這個extension。而在其中的resource/commercefacades-spring.xml文件中可以找到productConverter的定義:

第137行到139行表明實際注入的populators屬性是一個列表(List)，這個List里的每一個元素是ProductPopulator。 從List這個數據結構我們可以猜想到，Converter主要是通過調用1個或多個Populator來生成DTO對象的。

Populator

我們再來看看Populator這個接口的代碼，它定義了一個名為populate(SOURCE,TARGET)的方法。方法的注釋清楚地說明了Populator是用Source變量的字段值去生成(Populate)Target變量的字段值，如下圖所示。

回到我們的Product明細頁面的展示例子。在ProductPopulator中:

• Source對應Java類ProductModel

• Target對應Java類ProductData

可見, Populator一般用于從Service層的DAO對象生成Facade層的DTO對象。

關于Populator的實際例子, 我們可以看看ProductUrlPopulator這個類, 它是接口Populator的一個具體實現類, 位于package**de.hybris.platform.commercefacades.product.converters.populator**下面。從這個package下面我們也能發現很多其他的Populator，這也解釋了本文Converter章節里介紹的為什么Populator屬性注入的類型需要選擇為List。

從populate方法中可以看到:

• DTO ProductData里的code和name屬性的值都是直接取自DAO ProductModel里對應的同名屬性；

• DTO ProductData的url屬性則是第47行的resolve方法根據DAO ProductModel計算出來的。

這個resolve方法的使用，表明了Populator不只是簡單的把DAO對象的值設置到DTO對象中。在Hybris的標準實現里諸如Product url屬性這樣需要調用其它Service來處理后然后再展示到前端的例子還有很多。

比如商品的庫存，多貨幣價格等信息, 在數據庫端本來就沒有和產品信息存在同一張表，自然也不能直接從Product的DAO對象中獲取，而是需要在相關的Populator里調用單獨的物流處理和價格處理的Service來生成。

這里我們再回想下Hybris的三層結構圖。

設想下如果沒有Facade層和DTO對象，前端的Controller將不得不調用很多Service，返回很多單獨的Model（如產品，物流和價格信息）給頁面，加重頁面處理的負擔。而Hybris的Facade層包裝了Service層的復雜邏輯，為前端提供了簡明統一的DTO對象，大大降低了前端的處理復雜度。這正是面向對象設計模式中的Facade（外觀）模式的體現，因此我們能夠從Hybris的架構圖中發現Facade層的名字。

希望大家通過這篇文章對Hybris Facade層的Converter和Populator能有比較詳細的了解。下一篇我們將繼續介紹Hybris的Service層。

Jerry注:

優秀的產品總是有著相似的設計思路。本文介紹的DAO和DTO, 不僅僅出現在Hybris里，在SAP的很多其他產品里也有用到。

在SAP CRM里，從ABAP數據庫里取出的數據因為結構差異無法直接被SAP CRM的BSP UI消費，必須要在圖中的Generic Interaction Layer里做一個結構和格式的轉換:

下圖是SAP CRM UI上產品長文本字段的一個截圖:

這個長文本字段的值, 從數據庫取出到最后顯示在UI上，也經歷了在Populator(下圖的ABAP類: CL_CRM_PRODIL_LONGTEXT)里從DAO到DTO的轉換。

至此我們能發現無論是在SAP Hybris還是SAP CRM里，這種DAO到DTO的映射都體現在具體的代碼里。

而在SAP Business by Design, SAP Hybris Cloud for Customer和SAP S/4HANA里，這種DAO到DTO的映射關系則維護在一些模型里。這樣, 應用開發人員負責維護映射關系，而框架負責統一處理映射關系。即使將來因為業務變化導致這些映射關系也需要發生變化，此時可以僅修改維護映射關系的模型，而無需修改任何代碼。

SAP把底層模型層(Model Layer)和上層消費層(Consumption Layer)之間的存儲及解析映射關系模型的這一中間層稱為SADL(Service Adaptation Definition Layer, L在有的上下文里也稱為Language)。維護映射關系的模型則成為SADL模型。如下圖所示:

在這個系列的下一篇文章里，Jonathan將介紹Hybris Commerce的持久層設計原理。

要獲取更多Jerry的原創技術文章，請關注公眾號”汪子熙”或者掃描下面二維碼:

總結

以上是生活随笔為你收集整理的从产品展示页面谈谈Hybris系列之二: DTO, Converter和Populator的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。