簡介
這些準則為準則:設計子系統補充 J2EE 應用程式開發的特定指引。在閱讀這些 J2EE
專用準則之前,建議您先閱讀「準則:設計子系統」。這些準則適用於設計較粗略的子系統,而非個別的 EJB。如需 EJB 的準則,請參閱準則:Enterprise JavaBean (EJB)。
請注意,「應用程式用戶端」視為特殊的「設計子系統」。請參閱準則:J2EE 應用程式用戶端。
發展設計子系統
一開始找到子系統時,最初可能為技術中立。亦即,可能以介面、文字描述及一些狀態機來指定,指出期待的操作行為。不過,這種技術中立的子系統通常會逐漸演變而呈現特定的技術。
下列範例顯示技術中立的設計子系統如何演進為特定技術的子系統。
子系統規格(子系統的黑箱觀點)
子系統規格最初可能只塑造抽象的 UML 介面。
以「客戶」子系統的初步設計為例,請參閱圖 1。
圖 1:初步的設計 - 客戶子系統
ICustomerMgt 進一步定義為具有操作,例如 "getCustomerDetails" 和 "setCustomerDetails"。
隨著設計愈來愈詳細(作業:subsystem_design_real-time_design),特定的語言和技術元素將取代這些抽象介面。(您可以選擇保留較抽象的子系統模型;比方說,如果需要以多種語言或技術來實作相同的設計。關於這些選項的討論,請參閱概念:從設計對映至程式碼)。相對應的設計工作成果:使用案例實現會更新以符合介面變更。
在此範例中,圖 2 是「客戶」子系統的黑箱或規格觀點。「客戶」子系統中表示的後續設計應該是實體 EJB。初步的設計子系統會轉換成 EJB 介面,如下所示:
-
ICustomerMgt =>
-
CustomerHome ?EJBEntityHomeInterface?
-
ICustomer =>
-
Customer ?EJBRemoteInterface?
圖 2:客戶設計子系統的黑箱觀點
「設計子系統」公開的介面可能含有一般的 Java 介面、EJB 介面(例如 Java 介面)、 EJB 介面(遠端和 Home),甚至一或多個委派或存取類別,將一或多個存在的 EJB
全部隱藏起來。請注意,以上全部(包括 Java 介面)塑造為 UML 類別,不是 UML 介面(請參閱準則:J2EE 應用程式的介面)。例如,Session Bean 通常做外觀來存取一組關係密切的
Entity Bean。在此情況下,子系統只匯出 Session Bean 的介面。
訊息驅動 Bean 會不同步地耗用目的地(或端點)的訊息。因此,目的地也可以做為包含訊息驅動 Bean 的「設計子系統」的「介面」。
請注意,因為本端介面由相同「設計子系統」內的其他密切相關的 EJB 使用,且較常出現在子系統的實現中,較少出現在子系統公開的可見介面中。
如需 J2EE 應用程式的介面的相關資訊,請參閱準則:J2EE 應用程式的介面。如需建模 EJB 的相關資訊,請參閱準則:Enterprise JavaBean (EJB)。
子系統實現(子系統的白箱觀點)
「設計子系統」應該只公開用戶端需要的介面。因此,實作 EJB 的類別為子系統內部所擁有,在邏輯上為子系統實現的一部分。子系統實現可能變成:
-
一組分工合作的 EJB 和類別,隱藏在一或多個可見的委派或存取類別後面
-
單一 EJB,沒有分工合作的類別
繼續以先前的「客戶」子系統為例,子系統的實現包括:
-
CustomerEntityEJB(元件)?EJBEntityBean?
-
CustomerBean ?EJBImplementation?
-
其他的 Helper 類別
圖 3 顯示「設計子系統」的白箱觀點(亦即,在子系統之內)。請注意,EJB 類別的塑造方式如準則:Enterprise JavaBean (EJB)
所述。子系統的這種內部觀點稱為子系統實現。在此觀點中,可以看出用戶端並不知道決策。例如,在子系統的這種實現中,「資料存取物件 (DAO)」類別以 JDBC API 來存取持續資料。(在別種設計中,則可能採用儲存區管理的持續性。)如需
DAO 類別的相關資訊,請參閱準則:Enterprise JavaBean (EJB)。
圖 3:客戶設計子系統的白箱觀點
|