正體中譯與整理 : Fred Wang (http://fredwang.blogspot.com)
內容來源 : "Core J2EE Design Pattern"
這個Pattern用來解決甚麼問題?
跨層(presentation tier, business tier and integration tier)轉送多個資料元素, 並減少遠端呼叫造成網路的負擔。
J2EE應用系統用Session Facade 或Business Objects作為伺服器端商業元件並由其中的一些methods傳資料回需求端。這些商業元件常用如session beans與entity beans等遠端物件來實作。若這些商業元件採用較小的get及set methods，則需求端必需呼叫很多的getter methods才能取得所需的屬性內容值。
因為這些method的呼叫對enterprise bean而言都是遠端呼叫, 因此可能會造成效率上的問題。因為遠端呼叫會造成網路的負擔。即使需求端與EJB container在相同的JVM, OS或相同的實體機器上執行效能都會受影響。因此使用許多的遠端getter method的呼叫, 每次只傳回一點點資料, 這種方式非常沒有效率。
因此即使不是存取遠端元件，仍然需要存取封裝在不同層內的資料元件, 如商業層的Business Objects, 整合層的Data Access Objects, 仍需要以較大顆粒(傳遞物件)介面來傳送及與接收資料。
重點 :
. 需求端要存取其他層的元件來擷取或更新資料
. 要減少網路上遠端的需求次數。
. 要避免存取頻繁的應用系統造成高的網路流量使網路效能下降。
解決方案
- 使用Transfer Object來攜帶跨層間傳遞的多個資料元素。
Transfer Object用來讓跨層間的資料最佳化，Transfer Object將需求與回應間的傳送與接收的所有元素包含在單一個資料結構內。
Transfer Object以傳值的方式被傳送到需求端, 因此需求端對Transfer Object的所有呼叫, 是針對原始Transfer Object的副本，而非遠端的原始Transfer Object。
步驟 :
1. Component因需求來建立Transfer Object的instance並傳回給需求端
註 : Component可能是展示層的view helper, business delegate或command object; 或商業層的Business Object, Application Service或Service Facade等; 或整合層的Data Access Object。
2. 此時的Transfer Object為序列化的(serialized)並跨網路傳送到需求端, 需求端收到並使用這個Transfer Object的本地副本(local copy)
3. 需求端也可以產生自己的Transfer Object instance送到Component來執行資料更新。
實作上Transfer Object是一個Serializable plan old Java Object(POJO), 包含許多的members(attributes or fields), 且用單一的method call來完成所有資料的傳送。
實作策略 : (待續)
Class Diagram
參考 :
http://www.corej2eepatterns.com/Patterns2ndEd/TransferObject.htm
沒有留言:
張貼留言
歡迎提供意見, 謝謝 (註 : 留言經過版主審核通過才會發布)