邏輯模型：應用程式定義和規劃

COM+ 應用程式設計程式的第二個步驟是將概念模型分成三層架構的邏輯層：表示層或使用者服務、仲介層或商務服務，以及數據層或數據服務。 如果您不熟悉三層式架構，請參閱 使用三層式架構模型。

查看名詞和動詞的概念模型，以開始此程式。 名詞通常可以轉譯成商業物件（類別），而與其相關聯的動詞可以轉譯成動作（類別的方法）。 雖然很難將所有名詞定義為商業物件，但當您完成邏輯模型時，遺漏或錯誤就會變得很明顯。

大部分的商務對象最終都會在商務服務層中，其餘物件會分割在使用者服務層中的使用者介面對象和數據服務層中的數據對象之間。 使用三層式架構建立邏輯模型時，請記住下列事項：

• 概念設計中的某些名詞不會代表實際的實體數據片段，但可能代表系統上的動作或系統上的商業物件角色。 商業物件也可以是執行某種系統控制的服務，例如安全性的登入標識碼。
• 避免在概念模型中「讀取行之間」來建立模糊的商業物件。 這類商業物件可能不正確，您應該先仔細考慮，再將它們納入邏輯模型中。 如果它們看起來正確，請明確地將它們新增至概念模型。
• 避免建立表示相同資訊或函式的商業物件;在應用程式速度和效能方面，重複作業的成本可能很高。
• 判斷物件相依性。 概念模型中的某些名詞可能只是其他商業對象的屬性。 決定屬性是否可以獨立存在。 如果是，它應該會成為它自己的商業物件;如果不是，它應該與適當的商業對象結合。
• 避免建立嘗試執行太多動作的商業物件。 多載商務物件可能表示稍後花費更多時間來分隔程序代碼，而且可能是維護問題。 概念模型中的不同物件不應合併;它們應該保持個別的商業物件。 您可以使用程式代碼將其通用函式委派給商業物件，來處理任何相似之處。
• 拿掉任何未用於任何使用案例的商業物件。 如果物件是要容納未來的成長，請考慮在初始應用程式完成之後加以實作。

此時，您可以從計算機和程式代碼開始思考。 從這些商務服務中，判斷您需要作為使用者服務提供的顯示和輸入功能。 定義需要以數據服務的形式提供哪些數據表和預存程式。 若要完成邏輯模型，請定義每個服務的介面，並包含每個數據欄位的定義及其驗證規則。 也包含所有函式、其語法及其參數。

服務或物件定義不應包含實體實作的任何層面。 其目的是要為邏輯元件產生器提供明確的指導方針，讓其他程式設計人員能夠在實際完成之前使用元件的程式代碼段。 在邏輯模型設計中，您應該記錄每個畫面、函式和物件。 在您符合這些準則之前，請勿繼續進行實體模型或實作。 如果您在概念模型和邏輯模型未達成一致時繼續進行，則稍後會在開發週期中遇到嚴重問題。

COM+ 應用程式的累加開發很常見。 這包括建立最終的已知元件子集，並透過應用程式的每一層進行測試：用戶端、商務和數據層，透過數據記憶體。 此工作模型提供客戶和實作考慮之其他需求的深入解析。 此工作模型通常會在單一計算機上進行測試。

相關主題

概念模型：應用程式需求

實體模型：應用程式架構

使用三層式架構模型