.net數據設計與應用

將關系數據映射到業務實體的建議

要將關系數據映射到業務實體，請考慮以下建議：

• 花些時間來分析您的應用程序的邏輯業務實體并為之建立模型，不要為每個表定義一個單獨的業務實體。建立應用程序的工作方式模型的方法之一是使用統一建模語言 (UML)。UML 是一種形式設計注釋，用于在面向對象的應用程序中建立對象模型，并獲取有關對象如何表示自動過程、人機交互以及關聯的信息。有關詳細信息，請參閱 Modeling Your Application and Data。
  
  
• 不要定義單獨的業務實體來表示數據庫中的多對多表，可以通過在數據訪問邏輯組件中實現的方法來公開這些關系。例如，前面示例中的 OrderDetails 表沒有映射到單獨的業務實體，而是通過在 Order 數據訪問邏輯組件中封裝 OrderDetails 表來實現 Order 與 Product 表之間的多對多關系。
  
  
• 如果具有返回特定業務實體類型的方法，請把這些方法放在該類型對應的數據訪問邏輯組件中。例如，當檢索一個客戶的全部訂單時，返回值為 Order 類型，因此應在 Order 數據訪問邏輯組件中實現該功能。反之，當檢索訂購某特定產品的全部客戶時，應在 Customer 數據訪問邏輯組件中實現該功能。
  
  
• 數據訪問邏輯組件通常訪問來自單一數據源的數據。當需要聚合多個數據源的數據時，建議分別為訪問每個數據源定義一個數據訪問邏輯組件，這些組件可以由一個能夠執行聚合任務的更高級業務過程組件來調用。建議采用這種方法的原因有二：
  
  
  • 事務管理集中在業務過程組件中，不需要由數據訪問邏輯組件顯式控制。如果通過一個數據訪問邏輯組件訪問多個數據源，則需要把該數據訪問邏輯組件作為事務處理的根，這會給僅讀取數據的功能帶來額外的系統開銷。
    
    
  • 通常，并不是應用程序的所有區域都需要聚合，并且通過分離對數據的訪問，您可以單獨使用該類型，也可以在必要時將其用作聚合的一部分。

• 固有功能。DataSet 提供了內置功能，可以處理開放式并發（以及數據適配器）并支持復雜的數據結構。此外，有類型的 DataSet 還提供了數據驗證支持。
  
  
• 業務實體集合。DataSet 是為處理復雜的關系集合而設計的，因此不需要再編寫自定義代碼來實現這一功能。
  
  
• 維護。更改架構不會影響方法簽名。然而，如果使用的有類型的 DataSet 和程序集具有嚴格名稱，則必須按照新版本重新編譯數據訪問邏輯組件類，或在全局程序集緩存中使用發布者策略，或在配置文件中定義一個 <bindingRedirect> 元素。
  
  
• 序列化。DataSet 本身支持 XML 序列化，并且可以跨層序列化。

這種方法的缺點如下：

• 性能。實例化和封送處理 DataSet 會增加運行時負擔。
  
  
• 表示單個業務實體。DataSet 是為處理一組數據而設計的。如果您的應用程序主要處理實例數據，則標量值或自定義實體是更好的方法，后者不會影響性能。

將自定義業務實體組件作為輸入和輸出傳遞

這種方法的優點如下：

• 維護。更改架構不會影響數據訪問邏輯組件方法簽名。然而，如果業務實體組件包含在嚴格命名的程序集中，就會出現與有類型的 DataSet 同樣的問題。
  
  
• 業務實體集合�？梢詫⒆远�義業務實體組件的數組和集合傳入和傳出方法。

這種方法的缺點如下：

• 支持開放式并發。要方便地支持開放式并發，必須在數據庫中定義時間戳列并將其作為實例數據的一部分。
  
  
• 集成限制。當使用自定義業務實體組件作為數據訪問邏輯組件的輸入時，調用程序必須知道業務實體的類型，而這會限制不使用 .NET 的調用程序的集成。然而，如果調用程序使用自定義業務實體組件作為數據訪問邏輯組件的輸出，則上述問題并不會限制集成。例如，Web 方法可以返回從數據訪問邏輯組件返回的自定義業務實體組件，并使用 XML 序列化自動將該業務實體組件序列化為 XML。

將數據讀取器作為輸出返回

這種方法的優點如下：

• 性能。當需要快速呈現數據時，這種方法具有性能優勢，并且可以使用表示層代碼部署數據訪問邏輯組件。

這種方法的缺點如下：

• 遠程。建議不要在遠程方案中使用數據讀取器，因為它可能會使客戶端應用程序與數據庫保持長時間的連接。

配合使用數據訪問邏輯組件與存儲過程

可以使用存儲過程執行數據訪問邏輯組件支持的許多數據訪問任務。

優點

• 存儲過程通�？梢愿纳菩阅�，因為數據庫能夠優化存儲過程使用的數據訪問計劃并為以后的重新使用緩存該計劃。
  
  
• 可以在數據庫內分別設置各個存儲過程的安全保護。管理員可以授予客戶端執行某個存儲過程的權限，而不授予任何基礎表訪問權限。
  
  
• 存儲過程可以簡化維護，因為修改存儲過程通常比修改所部署的組件中的硬編碼 SQL 語句要容易。然而，隨著在存儲過程中實現的業務邏輯的增多，上述優勢會逐漸減弱。
  
  
• 存儲過程增大了從基礎數據庫架構進行抽象的程度。存儲過程的客戶端與存儲過程的實現細節和基礎架構是彼此分離的。
  
  
• 存儲過程會降低網絡流量。應用程序可以按批執行 SQL 語句而不必發出多個 SQL 請求。
  
  
• 盡管存儲過程具有上述優點，但仍有某些情況不適合使用存儲過程。

缺點

• 如果邏輯全部在存儲過程中實現，那么涉及廣泛業務邏輯和處理的應用程序可能會給服務器帶來過重負荷。這類處理包括數據傳輸、數據遍歷、數據轉換和大計算量操作。應把這類處理移到業務過程或數據訪問邏輯組件中，與數據庫服務器相比，它們具有更好的可縮放性。
  
  
• 不要把所有業務邏輯都放在存儲過程中。如果必須在 T - SQL 中修改業務邏輯，應用程序的維護和靈活性將成為問題。例如，支持多個 RDBMS 的 ISV 應用程序不應當分別為每個系統維護存儲過程。
  
  
• 通常，存儲過程的編寫與維護是一項專門技能，并非所有開發人員都能夠掌握。這會造成項目開發計劃的瓶頸。

配合使用數據訪問邏輯組件與存儲過程的建議

配合使用數據訪問邏輯組件與存儲過程時，請考慮以下建議：

• 公開存儲過程。數據訪問邏輯組件應當是向存儲過程名稱、參數、表、字段等數據庫架構信息公開的僅有組件。業務實體實現應不需要知道或依賴于數據庫架構。
  
  
• 使存儲過程與數據訪問邏輯組件相關聯。每個存儲過程只應被一個數據訪問邏輯組件調用，并應與調用它的數據訪問邏輯組件相關聯。例如，假設一個客戶向一個零售商訂貨。您可以編寫一個名為 OrderInsert 的存儲過程，用于在數據庫中創建訂單。在您的應用程序中，必須確定是從 Customer 數據訪問邏輯組件還是從 Order 數據訪問邏輯組件調用該存儲過程。Order 數據訪問邏輯組件處理所有與訂單相關的任務，而 Customer 數據訪問邏輯組件處理客戶姓名、地址等客戶信息，因此最好使用前者。
  
  
• 命名存儲過程。為要使用的數據訪問邏輯組件定義存儲過程時，所選擇的存儲過程名稱應當強調與之相關的數據訪問邏輯組件。這種命名方法有助于識別哪個組件調用哪個存儲過程，并為在 SQL 企業管理器中邏輯分組存儲過程提供了一種方法。例如，可以事先編寫名為 CustomerInsert、CustomerUpdate、CustomerGetByCustomerID、CustomerDelete 的存儲過程供 Customer 數據訪問邏輯組件使用，然后提供 CustomerGetAllInRegion 等更具體的存儲過程以支持您的應用程序的業務功能。
  
  注意：不要在存儲過程名稱前面使用前綴 sp_，這會降低性能。當調用一個以 sp_ 開頭的存儲過程時，SQL Server 始終會先檢查 master 數據庫，即使該存儲過程已由數據庫名稱進行限定。
  
  
• 解決安全性問題。如果接受用戶輸入以動態執行查詢，請不要通過沒有使用參數的連接值來創建字符串。如果使用 sp_execute 執行結果字符串，或者不使用 sp_executesql 參數支持，則還應避免在存儲過程中使用字符串連接。

管理鎖定和并發

某些應用程序在更新數據庫數據時采用“后進有效”(Last in Wins) 法。使用“后進有效”法更新數據庫時不會將更新與原始記錄相比較，因此可能會覆蓋掉自上次刷新記錄以來其他用戶所做的所有更改。然而，有時應用程序卻需要在執行更新之前確定數據自最初讀取以來是否被更改。

數據訪問邏輯組件可以實現管理鎖定和并發的代碼。管理鎖定和并發的方法有兩種：

• 保守式并發。為進行更新而讀取某行數據的用戶可以在數據源中對該行設置一個鎖定。在該用戶解除鎖定之前，其他任何用戶都不能更改該行。
  
  
• 開放式并發。用戶在讀取某行數據時不鎖定該行。其他用戶可以在同一時間自由訪問該行。當用戶要更新某行數據時，應用程序必須確定自該行被讀取以來其他用戶是否進行過更改。嘗試更新已經過更改的記錄會導致并發沖突。

// 創建 ProductDALC 對象
ProductDALC dalcProduct = new ProductDALC();

// 對 ProductDALC 調用一個方法以獲取一個包含全部產品信息的 DataSet
DataSet dsProducts = dalcProduct.GetProducts();

// 在客戶端中使用 DataSet。 例如，把該 DataSet 綁定到用戶界面控件
dataGrid1.DataSource = dsProducts.Tables[0].DefaultView;
dataGrid1.DataBind();

// 然后，把更新后的 DataSet 傳遞給 ProductDALC，將更改
// 保存到數據庫
dalcProduct.UpdateProducts(dsProducts);

您還可以在運行時查詢和修改 DataSet 中的表、約束及關系。

將業務實體表示為通用 DataSet 的優點如下：

• 靈活性。DataSet 可以包含數據的集合，能夠表示復雜的數據關系。
  
  
• 序列化。在層間傳遞時，DataSet 本身支持序列化。
  
  
• 數據綁定�？梢园� DataSet 綁定到 ASP.NET 應用程序和 Windows 窗體應用程序的任意用戶界面控件。
  
  
• 排序與過濾�？梢允褂� DataView 對象排序和過濾 DataSet。應用程序可以為同一個 DataSet 創建多個 DataView 對象，以便用不同方式查看數據。
  
  
• 與 XML 的互換性�？梢杂� XML 格式讀寫 DataSet。這種方法在遠程和脫機應用程序中很有用，它可以用 XML 格式接收 DataSet，然后在本地重新創建該 DataSet 對象。應用程序在與數據庫斷開連接后，還可以將 DataSet 保持為 XML 格式。
  
  
• 元數據的可用性�？梢杂� XSD 架構的形式為 DataSet 提供完整的元數據。還可以使用 DataSet、DataTable、DataColumn、Constraint 和 Relation 類中的方法以編程方式為 DataSet 獲取元數據。
  
  
• 開放式并發。在更新數據時，可以配合使用數據適配器與 DataSet 以方便地執行開放式并發檢查。
  
  
• 可擴展性。如果修改了數據庫架構，則適當情況下數據訪問邏輯組件中的方法可以創建包含修改后的 DataTable 和 DataRelation 對象的 DataSet。數據訪問邏輯組件方法簽名并不改變�？梢詫⒄{用應用程序修改為使用該 DataSet 中的這些新元素。

將業務實體表示為通用 DataSet 的缺點如下：

• 客戶端代碼必須通過 DataSet 中的集合訪問數據。要訪問 DataSet 中的表，客戶端代碼必須使用整數索引生成器或字符串索引生成器來索引 DataTable 集合。要訪問特定列，必須使用列編號或列名稱索引 DataColumn 集合。以下示例顯示了如何訪問 Products 表中第一行的 ProductName 列：
  
  

  // 獲取所調用的名為 dsProducts 的 DataSet 的第一行的 // 產品名稱。 注意，該集合是基于零的。 String str = (String)dsProducts.Tables["Products"].Rows[0]["ProductName"]; ...

  
  
  注意：這里沒有這些索引生成器的編譯時檢查。如果指定一個無效的表名稱、列名稱或列類型，會在運行時捕獲該錯誤。使用通用 DataSet 時不支持 IntelliSense。
  
  
• 實例化和封送處理的成本很高。DataSet 需要創建多個子對象（DataTable、DataRow 和 DataColumn），這意味著在實例化和封送處理時，DataSet 會比 XML 字符串或自定義實體組件花費更長的時間。隨著數據量的增大，創建 DataSet 內部結構的系統開銷將明顯少于將數據填充到 DataSet 中所需的開銷，因此 DataSet 的相對性能會隨之提高。
  
  
• 專用字段。您不能選擇隱藏信息。

將業務實體表示為有類型的 DataSet

有類型的 DataSet 是包含具有嚴格類型的方法、屬性和類型定義以公開 DataSet 中的數據和元數據的類。有關如何創建有類型的 DataSet 的示例，請參閱附錄中的如何創建有類型的 DataSet。

下面列出了有類型的 DataSet 與通用 DataSet 相比的優缺點。注意，有類型的 DataSet 的實例化和封送處理性能與通用 DataSet 基本相同。

將業務實體表示為有類型的 DataSet 的優點如下：

• 代碼易讀。要訪問有類型的 DataSet 中的表和列，可以使用有類型的方法和屬性，如以下代碼所示：
  
  

  ... // 獲取所調用的名為 dsProducts 的有類型的 DataSet 的第一行的 // 產品名稱。 注意，該集合是基于零的。 String str = dsProducts.Products[0].ProductName; ...

  
  
  在本示例中，dsProducts 是有類型的 DataSet 的一個實例。該 DataSet 有一個 DataTable，它由一個命名為 Products 的屬性公開。該 DataTable 中的列由 ProductName 等屬性公開，后者返回列的相應數據類型（而不僅僅返回對象）。
  
  有類型的方法和屬性的提供使得使用有類型的 DataSet 比使用通用 DataSet 更方便。使用有類型的 DataSet 時，IntelliSense 將可用。
  
  
• 編譯時類型檢查。無效的表名稱和列名稱將在編譯時而不是在運行時檢測。

將業務實體表示為有類型的 DataSet 的缺點如下：

• 部署。必須將包含有類型的 DataSet 類的程序集部署到使用業務實體的所有層。
  
  
• 支持企業服務 (COM+) 調用程序。如果有類型的 DataSet 將由 COM+ 客戶端使用，則必須為包含該有類型的 DataSet 類的程序集提供一個嚴格名稱，并且必須在客戶端計算機上注冊。通常，該程序集安裝在全局程序集緩存中。這些也是自定義實體類所要求的步驟，如本文后面所述。
  
  
• 可擴展性問題。如果修改了數據庫架構，則可能需要重新生成有類型的 DataSet 類以支持新架構。重新生成過程將不會保留在有類型的 DataSet 類中實現的任何自定義代碼。必須將包含有類型的 DataSet 類的程序集重新部署到所有客戶端應用程序中。
  
  
• 實例化。您不能使用 new 運算符來實例化類型。
  
  
• 繼承。有類型的 DataSet 必須從 DataSet 類繼承，這會禁止使用任何其他基本類。

定義自定義業務實體組件

表示業務實體的自定義類通常包含以下成員：

• 用于在本地緩存業務實體的數據的專用字段。這些字段在數據訪問邏輯組件從數據庫檢索數據時保存數據庫數據的一個快照。
  
  
• 用于訪問實體的狀態和訪問實體內數據的子集及層次結構的公共屬性。這些屬性的名稱可以與數據庫的列名稱相同，但這并不是一個絕對要求�？梢愿鶕�您的應用程序的需要選擇屬性名，而不必使用數據庫中的名稱。
  
  
• 用以使用實體組件中的數據執行本地化處理的方法和屬性。
  
  
• 用以通知實體組件內部狀態變化的事件。

圖9 所示為使用自定義實體類的方法。注意，實體類并不知道數據訪問邏輯組件或基礎數據庫；所有數據庫訪問都由數據訪問邏輯組件執行，以集中數據訪問策略和業務邏輯。此外，在層間傳遞業務實體數據的方式與表示業務實體的格式也沒有直接關系；例如，可以在本地將業務實體表示為對象，而用另一種方法（如標量值或 XML）將業務實體數據傳遞到其他層。

• 選擇使用結構還是使用類。對于不包含分層數據或集合的簡單業務實體，可以考慮定義一個結構來表示業務實體。對于復雜的業務實體或要求繼承的業務實體，可將實體定義為類。
  
  
• 表示業務實體的狀態。對于數字、字符串等簡單值，可以使用等價的 .NET 數據類型來定義字段。有關說明如何定義自定義實體的代碼示例，請參閱附錄中的如何定義業務實體組件。
  
  
• 表示自定義業務實體組件中的子集合和層次結構。表示自定義實體中的數據的子集合和層次結構的方法有兩種：
  
  
  • .NET 集合（例如 ArrayList）。.NET 集合類為大小可調的集合提供了一個方便的編程模型，還為將數據綁定到用戶界面控件提供了內置的支持。
    
    
  • DataSet。DataSet 適合于存儲來自關系數據庫或 XML 文件的數據的集合和層次結構。此外，如果需要過濾、排序或綁定子集合，也應首選 DataSet。
    
    
  • 有關說明如何表示自定義實體中數據的集合和層次結構的代碼示例，請參閱附錄中的如何表示自定義實體中數據的集合和層次結構。
• 支持用戶界面客戶端的數據綁定。如果自定義實體將要由用戶界面使用并且希望利用自動數據綁定，可能需要在自定義實體中實現數據綁定。請考慮以下方案：
  
  
  • Windows 窗體中的數據綁定。您可以將實體實例的數據綁定到控件而不必在自定義實體中實現數據綁定接口。也可以綁定實體的數組或 .NET 集合。
    
    
  • Web 窗體中的數據綁定。如果不實現 IBindingList 接口，則不能將實體實例的數據綁定到 Web 窗體中的控件。然而，如果只想綁定集合，則可以使用數組或 .NET 集合而不必在自定義實體中實現 IBindingList 接口。
  有關說明如何將自定義實體綁定到用戶界面控件的代碼示例，請參閱附錄中的如何將業務實體組件綁定到用戶界面控件。
  
  
• 公開內部數據更改的事件。公開事件可以獲得豐富的客戶端用戶界面設計，因為它使得無論數據顯示在哪里都可以對其進行刷新。事件應當只針對內部狀態，而不是針對服務器上的數據更改。有關說明如何公開自定義實體類中的事件的代碼示例，請參閱附錄中的如何公開業務實體組件中的事件。
  
  
• 使業務實體可序列化。使業務實體可序列化可以將業務實體的狀態保持在中間狀態而不進行數據庫交互。這樣可以方便脫機應用程序的開發和復雜用戶界面過程的設計，即在完成前不會影響業務數據。序列化有兩種類型：
  
  
  • 使用 XmlSerializer 類進行 XML 序列化。如果只需要把公共字段和公共讀/寫屬性序列化為 XML，則可以使用 XML 序列化。注意，如果從 Web 服務返回業務實體數據，對象將通過 XML 序列化自動序列化為 XML。
    
    您可以對業務實體執行 XML 序列化而無需在實體中實現任何附加代碼。然而，只有對象中的公共字段和公共讀/寫屬性被序列化為 XML。專用字段、索引生成器、專用屬性、只讀屬性及對象圖不會被序列化。您可以使用自定義實體中的屬性控制結果 XML。有關將自定義實體組件序列化為 XML 格式的詳細信息，請參閱附錄中的如何將業務實體組件序列化為 XML 格式。
    
    
  • 使用 BinaryFormatter 或 SoapFormatter 類進行格式序列化。如果需要序列化對象的所有公共字段、專用字段及對象圖，或者需要與遠程服務器之間傳遞實體組件，則可以使用格式序列化。
    
    格式類將序列化對象的所有公共和專用字段及屬性。BinaryFormatter 將對象序列化為二進制格式，SoapFormatter 將對象序列化為 SOAP 格式。使用 BinaryFormatter 的序列化比使用 SoapFormatter 的序列化速度要快。要使用任何一個格式類，都必須將實體類標記為 [Serializable] 屬性。如果需要顯式控制序列化格式，您的類還必須實現 ISerializable 接口。有關如何使用格式序列化的詳細信息，請參閱附錄中的如何將業務實體組件序列化為二進制格式及如何將業務實體組件序列化為 SOAP 格式。
    
    注意：還原序列化某個對象時，不會調用默認的構造函數。對還原序列化添加這項約束，是出于性能方面的考慮。

定義自定義實體的優點如下：

• 代碼易讀。要訪問自定義實體類中的數據，可以使用有類型的方法和屬性，如以下代碼所示：
  
  

  // 創建一個 ProductDALC 對象 ProductDALC dalcProduct = new ProductDALC(); // 使用該 ProductDALC 對象創建和填充一個 ProductEntity 對象。 // 此代碼假設 ProductDALC 類有一個名為 GetProduct 的方法， // 該方法使用 Product ID 作參數（本例中為 21），并返回一個 // 包含該產品的所有數據的 ProductEntity 對象。 ProductEntity aProduct = dalcProduct.GetProduct(21); // 更改該產品的產品名稱 aProduct.ProductName = "Roasted Coffee Beans";

  
  
  在上述示例中，產品是一個名為 ProductEntity 的自定義實體類的一個實例。ProductDALC 類有一個名為 GetProduct 的方法，后者創建一個 ProductEntity 對象，將某個特定產品的數據填充到該對象，然后返回 ProductEntity 對象。調用應用程序可以使用 ProductName 等屬性訪問 ProductEntity 對象中的數據，并且可以調用方法以操作該對象。
  
  
• 封裝。自定義實體可以包含方法以封裝簡單的業務規則。這些方法操作緩存在實體組件中的業務實體數據，而不是訪問數據庫中的實時數據。請考慮以下示例：
  
  

  // 調用一個在 ProductEntity 類中定義的方法。 aProduct.IncreaseUnitPriceBy(1.50);

  
  
  在上述示例中，調用應用程序對 ProductEntity 對象調用一個名為 IncreaseUnitPriceBy 的方法。在調用應用程序對 ProductDALC 對象調用相應方法，從而將 ProductEntity 對象保存到數據庫之前，這一更改并不是永久性的。
  
  
• 構建復雜系統的模型。在構建復雜域問題（在不同業務實體之間存在很多交互）的模型時，可以定義自定義實體類，從而將復雜性隱藏在經過很好定義的類接口的后面。
  
  
• 本地化驗證。自定義實體類可以在其屬性存取器中執行簡單的驗證測試以檢測無效的業務實體數據。有關詳細信息，請參閱如何在業務實體組件的屬性存取器中驗證數據。
  
  
• 專用字段。您可以隱藏不希望向調用程序公開的信息。

定義自定義實體的缺點如下：

• 業務實體集合。自定義實體表示的是單個業務實體，而不是一個業務實體集合。要保存多個業務實體，調用應用程序必須創建一個數組或一個 .NET 集合。
  
  
• 序列化。您必須在自定義實體中實現自己的序列化機制�？梢允褂脤傩詠砜刂茖嶓w組件的序列化方式，也可以通過實現 ISerializable 接口來控制自己的序列化。
  
  
• 表示業務實體中的復雜關系和層次結構。您必須在業務實體組件中實現自己的關系和層次結構表示機制。如前面所述，DataSet 通常是實現這一目的的最簡單方式。
  
  
• 搜索和排序數據。您必須定義自己的機制來支持實體的搜索和排序。例如，可以通過實現 IComparable 接口以便將實體組件保存在一個 SortedList 集合或 Hashtable 集合中。
  
  
• 部署。您必須在所有物理層部署包含自定義實體的程序集。
  
  
• 支持企業服務 (COM+) 客戶端。如果一個自定義實體將由 COM+ 客戶端使用，則必須為包含該實體的程序集提供一個嚴格名稱，并且必須在客戶端計算機上注冊。通常，該程序集安裝在全局程序集緩存中。
  
  
• 可擴展性問題。如果修改了數據庫架構，則可能需要修改自定義實體類并重新部署程序集。

定義帶有 CRUD 行為的自定義業務實體組件

在定義一個自定義實體時，可以提供方法以完全封裝對基礎數據訪問邏輯組件的 CRUD 操作。這是比較傳統的面向對象的方法，可能適用于復雜的對象域�？蛻舳藨�用程序不再直接訪問數據訪問邏輯組件類，而是創建一個實體組件并對該實體組件調用 CRUD 方法。這些方法將調用基礎的數據訪問邏輯組件。

圖10 所示為帶有 CRUD 行為的自定義實體類的作用。

定義帶有 CRUD 行為的自定義實體類的優點如下：

• 封裝。自定義實體可以封裝由基礎數據訪問邏輯組件定義的操作。
  
  
• 與調用程序的接口。調用程序必須只處理一個接口來保持業務實體數據。不必直接訪問數據訪問邏輯組件。
  
  
• 專用字段。您可以隱藏不希望向調用程序公開的信息。

定義帶有 CRUD 行為的自定義實體類的缺點如下：

• 處理業務實體集合。自定義實體中的方法屬于單個業務實體實例。要支持業務實體集合，可以定義靜態方法以讀取或返回一個數組或一個實體組件集合。
  
  
• 開發時間長。傳統的面向對象方法通常比使用現有對象（如 DataSet）需要更多的設計和開發工作。

表示數據和在層間傳遞數據的建議

在您的應用程序中表示數據的方式以及在層間傳遞數據的方式不一定要相同。然而，一套一致而有限的格式能夠降低對附加轉換層的需要，從而提高性能并方便維護。

應根據自己特定的應用程序要求和操作數據的方式選擇數據格式。這里并沒有一個通用的表示方式，特別是由于當今的許多應用程序都需要支持多個調用程序。然而，我們還是建議遵循以下一般原則：

• 如果您的應用程序主要處理集合并需要排序、搜索和數據綁定等功能，則建議采用 DataSet。但如果應用程序處理實例數據，則采用標量值的效果會更好。
  
  
• 如果您的應用程序主要處理實例數據，則自定義業務實體組件可能是最佳選擇，因為它們可以消除一個 DataSet 表示一行時的系統開銷。
  
  
• 大多數情況下，應把應用程序設計為使用 XML 文檔、DataSet 等以數據為中心的格式�？梢岳�用 DataSet 提供的靈活性及固有功能來更方便地支持多個客戶端、減少自定義代碼的數量并使用為大多數開發人員所熟知的編程 API。雖然以面向對象的方式操作數據有很多好處，但自定義編碼復雜的業務實體會使開發和維護成本隨所提供功能的數量成比例增加。

事務處理

當今的大多數應用程序都需要支持事務處理以保持系統數據的完整性。事務處理的管理方法有多種，但每種方法都可歸于以下兩種基本編程模型之一：

• 手動事務處理。直接在組件代碼或存儲過程中編寫使用 ADO.NET 或 Transact-SQL 事務處理支持功能的代碼。
  
  
• 自動事務處理。使用企業服務 (COM+) 為 .NET 類添加聲明屬性以便在運行時指定對象的事務性要求。使用這種模型可以方便地配置多個組件以執行同一事務中的工作。

本節提供一些指導原則和建議，幫助您在數據訪問邏輯組件和業務實體組件中實現事務處理支持。

實現事務處理

在大多數環境中，事務處理的根本是業務過程而不是數據訪問邏輯組件或業務實體組件。這是因為業務過程一般要求事務處理跨多個業務實體而不僅僅是單個業務實體。

然而，也可能出現在沒有高層次業務過程的幫助下對單個業務實體執行事務性操作的情況。例如，要把一個新客戶添加到前面討論的數據庫中，您必須執行以下操作：

• 在 Customer 表中插入新的一行。
  
  
• 在 Address 表中插入新的一行或多行。

只有這兩個操作都成功后客戶才會被添加到數據庫中。如果 Customer 業務實體不會成為啟動該事務處理的更大的業務過程的一部分，則應在 Customer 業務實體中使用手動事務處理。手動事務處理不要求與 Microsoft 分布式事務處理協調器 (DTC) 之間進行任何進程間通信，因此比自動事務處理要快得多。


圖11 所示為確定使用手動事務處理還是自動事務處理的方法。由于 COM+ 事務處理的系統開銷，建議將事務處理放到數據庫中并在存儲過程中控制事務性行為（如果可能）。

注意：如果從基于 ASP.NET 的客戶端進行調用，并且沒有用于啟動事務處理的業務過程，則您可能會從 ASP.NET 代碼中啟動該事務處理。這種設計并不好；您決不能從基于 ASP.NET 的客戶端啟動事務處理，而應將數據的展示與業務過程相分離。此外，由于網絡滯后等問題還會導致性能問題，因為這是要實際部署在其他層上的最常見的層。

在數據訪問邏輯組件中使用手動事務處理的建議

在數據訪問邏輯組件中實現手動事務處理時，請考慮以下建議：

• 盡可能在存儲過程中執行處理。使用 Transact-SQL 語句 BEGIN TRANSACTION、END TRANSACTION 和 ROLLBACK TRANSACTION 控制事務處理。
  
  
• 如果沒有使用存儲過程，并且也不會從業務過程中調用數據訪問邏輯組件，則可以使用 ADO.NET 來編程控制事務處理。

在數據訪問邏輯組件中使用自動事務處理的建議

雖然 COM+ 事務處理會帶來一些系統開銷，但自動事務處理能夠提供比手動事務處理更簡單的編程模式，而且在事務處理跨多個分布式數據源（與 DTC 一起工作）時必須使用自動事務處理。在數據訪問邏輯組件中實現自動事務處理時，請考慮以下建議：

• 數據訪問邏輯組件必須是從 System.EnterpriseServices 命名空間中的 ServicedComponent 類繼承而來。注意，使用 COM+ 服務注冊的所有程序集都必須具有嚴格的名稱。
  
  
• 使用 Transaction(TransactionOption.Supported) 屬性注釋數據訪問邏輯組件，以便可以在同一組件中執行讀寫操作。與 Transaction(TransactionOption.Required) 不同，此選項在不需要事務處理時避免了不必要的系統開銷，而前者始終會要求事務處理。

以下代碼示例顯示了如何在數據訪問邏輯組件類中支持自動事務處理：

using System.EnterpriseServices;

[Transaction(TransactionOption.Supported)]
public class CustomerDALC : ServicedComponent
{
  ...
}

如果使用自動事務處理，則數據訪問邏輯組件應在事務處理中表明操作是否成功。如果要隱式表明，應使用 AutoComplete 屬性注釋您的方法并在操作失敗時發出一個異常。如果要顯式表明，應對 ContextUtil 類調用 SetComplete 或 SetAbort 方法。

在業務實體組件中使用自動事務處理

在實現帶有行為的自定義業務實體組件時，可以使用自動事務處理來指定這些對象的事務性行為。有關使用自動事務處理指定業務實體組件事務性行為的建議與前述有關在數據訪問邏輯組件中實現自動事務處理的建議相同。

注意：如果業務實體組件不包含任何要求其在事務處理中表明是否成功的業務邏輯，則它可以忽略事務處理環境。自定義業務實體組件不需要從 ServicedComponent 繼承；事務處理環境仍將繼續其流程，但實體組件將忽略事務處理環境。

驗證

您可以在應用程序的許多層上進行數據驗證。各層適用不同的驗證類型：

• 在提交數據之前，客戶端應用程序可以在本地驗證業務實體數據。
  
  
• 使用 XSD 架構接收業務文檔時，業務過程可以驗證這些文檔。
  
  
• 數據訪問邏輯組件和存儲過程可以驗證數據，以確保引用的完整性并強制遵循約束以及重要的業務規則。

常用驗證有兩種：

• 即時點驗證。這是在一個特定時點執行的驗證。例如，在接收 XML 文檔時由業務過程對其進行驗證。
  
  
• 連續驗證。這是在應用程序的許多不同層次上持續進行的一種驗證。連續驗證的示例包括：
  
  
  • 用戶界面可以指定字段的最大長度以防止用戶輸入過長的字符串。
    
    
  • DataSet 可以指定數據列的最大長度。
    
    
  • 自定義業務實體組件可以對實體數據執行范圍檢查、長度檢查、非空檢查以及其他簡單測試。
    
    
  • 數據訪問邏輯組件、存儲過程和數據庫本身可以執行類似的測試，以便在將數據保存到數據庫之前確保其有效性。

有時，您可能希望實現額外的聚合過程或轉換過程。這種方法在驗證和轉換經常變化時可能很有用，但會損失性能。例如，如果一個 ISV 想要使用相同的組件支持數據庫架構的兩個版本，則您可以創建一個單獨的組件來執行兩個數據庫架構版本之間的驗證和轉換。

如何使用 XSD 架構驗證 XML

要使用 XSD 架構驗證 XML 文檔，請執行以下步驟：

1. 創建一個 XmlValidatingReader 對象作為 XmlTextReader 對象的包裝，如以下代碼所示：
   
   

   ' 創建 XmlValidatingReader 對象，以讀取和驗證 Product.xml XmlTextReader tr = new XmlTextReader("Product.xml"); XmlValidatingReader vr = new XmlValidatingReader(tr);

   
   
   
2. 通過使用 ValidationType 枚舉指定所需的驗證類型。.NET Framework 支持三種類型的 XML 驗證：
   
   文檔類型定義 (DTD)；指定 ValidationType.DTD
   
   Microsoft XML 精簡數據 (XDR) 架構；指定 ValidationType.XDR
   
   W3C 標準 XSD 架構；指定 ValidationType.Schema
   
   以下代碼顯示了 ValidationType 枚舉的使用：
   
   

   vr.ValidationType = ValidationType.Schema; ' 指定 XSD 架構驗證

   
   
   
3. 注冊一個驗證事件處理程序方法，如以下代碼所示：
   
   

   vr.ValidationEventHandler += new ValidationEventHandler(MyHandlerMethod);

   
   
   
4. 提供一個驗證事件處理程序方法的實現，如以下代碼所示：
   
   

   public void MyHandlerMethod(object sender, ValidationEventArgs e) { Console.WriteLine("驗證錯誤:" + e.Message); }

   
   
   
5. 讀取和驗證文檔，如以下代碼所示。驗證錯誤將被驗證事件處理程序方法拾取。
   
   

   try { while (vr.Read()) { // 適當處理 XML 數據... } } catch (XmlException ex) { Console.WriteLine("XmlException: " + ex.Message); } vr.Close();

如何在業務實體組件的屬性存取器中驗證數據

以下代碼片段顯示了如何在自定義實體的屬性存取器中進行簡單驗證。如果驗證測試失敗，您可以發出一個異常以顯示問題的性質。也可以在屬性存取器集合中使用正則表達式來驗證特定的數據和格式。

public class ProductDALC
{
 ...
  public short ReorderLevel
  {
    get { return reorderLevel; }
  }
  set
  {
    if (value < 0)
    {
      throw new ArgumentOutOfRangeException("ReorderLevel 不能為負數。");
    }
    reorderLevel = value;
  }

  // 加上 ProductDALC 類中的其他成員...
}

異常管理

當 .NET 應用程序出現錯誤時，通常的建議是發出異常而不是從方法返回錯誤值。這一建議暗示了您編寫數據訪問邏輯組件和業務實體組件的方式。異常大體上有兩種：

技術異常，它包括：

• ADO.NET
  
  
• 數據庫連接
  
  
• 資源（如數據庫、網絡共享、消息隊列等）不可用
  
  業務邏輯異常，它包括：
  
  
• 驗證錯誤
  
  
• 實現業務邏輯的存儲過程中的錯誤
  
  在數據訪問邏輯組件中管理異常的建議
  
  數據訪問邏輯組件應該傳播異常，并且僅在能夠使客戶端對異常的管理更加容易時才包裝異常類型。將異常包裝為兩種主要異常類型（技術異常和業務異常）有利于各種可能的調用程序的異常處理結構和異常發布邏輯。
  
  您的應用程序應當發布異常信息�？梢詫⒓夹g異常發布到一個由系統管理員或 Windows 管理規范 (WMI) 監視工具（如 Microsoft Operations Manager）監視的日志中；將業務異常發布到一個特定的應用程序日志中。通常，應允許從數據訪問邏輯組件傳播異常并允許由調用程序發布異常，以便您了解異常的整個環境。
  
  以下示例說明了這些建議：
  
  

  public class CustomerDALC { public void UpdateCustomer(Dataset aCustomer) { try { // 更新數據庫中的客戶... } catch (SqlException se) { // 捕獲并包裝異常，然后重新發出 throw new DataAccessException("數據庫不可用", se); } finally { // 清除代碼 } } }

  
  
  在業務實體組件中管理異常的建議
  
  業務實體組件應當向調用程序傳播異常。在業務實體組件執行驗證或者當調用程序試圖執行某一操作而未提供該操作所需的數據時，業務實體組件也可以產生異常。
  
  以下示例顯示了業務實體組件如何產生異常。在此示例中，如果沒有提供客戶的名字，Update 方法將發出一個異常：
  
  

  public class CustomerEntity { public void Update() { // 檢查用戶已提供了所需數據。這里是客戶 // 的名字 if (FirstName == "" ) { // 發出一個已定義的新的應用程序異常 throw new MyArgumentException("您必須提供名字。"); } ... } }

  
  
  有關在 .NET 應用程序中處理異常的詳細信息，請參閱 Exception Management in .NET�？梢詮� Exception Management Application Block 提供的 ApplicationException 類或 BaseApplicationException 類中繼承自定義技術異常和自定義業務異常。

授權與安全性

學習向 Microsoft .NET 應用程序公開數據的最佳方式，以及如何實現一個有效的策略以便在分布式應用程序的層間傳遞數據。（本文包含一些指向英文站點的鏈接。）

本節說明如何將安全性應用于數據訪問邏輯組件和業務實體組件。.NET 公共語言運行庫使用權限對象實現其對托

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: net 設計 數據 應用 與