面向物件應用服務層架構設計指南

前言：為什麼需要細分應用服務層？

典型三層架構中，應用服務層 (Business Logic Layer) 集中業務邏輯，是系統核心。但許多專案將資料庫操作、業務邏輯、甚至 UI 顯示混雜，導致耦合度高、難以維護。本文提出將應用服務層進一步垂直細分為四個子層，並橫向統一設計策略，構建高內聚、低耦合、可擴充的企業級應用架構。

架構評判標準

• 高內聚、低耦合：橫向 (模組/類) 與縱向 (層級) 均需達標。
• 層次清晰、功能單一：同一功能僅在一處實現，避免重複與衝突。
• 易於實現：架構複雜度須在團隊技術能力範圍內。
• 可升級、可擴充：介面技術預留變化點，不影響現有應用。
• 利於團隊協作：如業務外觀層分離 UI 設計與邏輯開發。
• 效能平衡：靈活性優先，硬體升級可補償效能損耗。

應用服務層四大子層

1. 資料實體層 - 物件與關聯映射 (O/R Mapping)

現實實體對應為「實體類」(Entity Class)。核心挑戰：

• 統一資料表示：單一物件與集合處理方式一致 (陣列、強型別 Collection、DataSet)。
• O/R Mapping 策略：XML 配置檔描述類別與資料表映射，避免硬編碼。
• 粒度控制：粗粒度物件 (含明細集合) vs 細粒度物件。

主流方案對比：

2. 資料存取層 - DAO 模式與事務管理

封裝資料庫差異，提供統一存取介面。

• 核心介面：IEntityDAO (Insert/Update/Delete/FindByPK)。
• 基底實作：AbstractSingleTableDAO、AbstractMultiTableDAO 封裝單/多表 CRUD，實作 IDisposable。
• 通用持久化管理器：PersistenceManager 針對單表映射物件自動存取。
• 事務支援：J2EE 容器事務、JDO、Websharp 封裝 COM+ 及 ADO.NET 連線事務。

3. 業務邏輯層 - 物件互動與事務邊界

操作實體物件而非直接操作資料庫。框架必須提供事務管理服務：

• 資料庫連線事務：效能佳，但不支援跨資料庫。
• 外部事務服務 (COM+/JTA)：支援分散式事務，大數據量下效能差距縮小。

// Websharp 事務範例：入庫單處理
public void StoreIntoWarehouse(EntityData insertForm)
{
    TransactionManager tm = new TransactionManager();
    // 遍歷明細，更新產品庫存
    foreach (DataRow row in insertForm.Tables["FormDetail"].Rows)
    {
        EntityData product = productDAO.FindByPrimaryKey(row["ProductID"]);
        product["CurrentCount"] = (decimal)product["CurrentCount"] + (decimal)row["InCount"];
        tm.AddMethod(new TransactionManagedFunction(productDAO.UpdateEntity), product);
    }
    tm.AddMethod(new TransactionManagedFunction(formDAO.InsertEntity), insertForm);
    tm.ExecuteMethods(); // 原子提交
}

4. 業務外觀層 - 解耦服務提供者與消費者

基於 Facade 模式，目的：

• 隔離 UI 與業務邏輯變更。
• 支援多種客戶端 (WinForm、Web、Web Service) 共用邏輯。
• 模組間解耦，降低系統整體耦合度。
• 團隊縱向分工：UI 設計師對介面，邏輯工程師對實作。

架構裁剪與取捨

小型系統可省略業務邏輯層 (併入實體控制層) 或業務外觀層 (UI 直呼邏輯)。關鍵在於專案內統一策略，避免同一問題多種解法造成維護災難。

框架與知識管理

統一架構框架是公司知識資產的載體，凝聚經驗智慧，新人上手快，利於長期演進。Websharp 提供 VS.NET 整合代碼生成器，將規範落地為工具輔助。