自定义实体类简介
摘要：有些情況下，非類型化的 DataSet 可能并非數據操作的最佳解決方案。本指南的目的就是探討 DataSet 的一種替代解決方案，即：自定義實體與集合。（本文包含一些指向英文站點的鏈接。）
引言
ADODB.RecordSet 和常常被遺忘的 MoveNext 的時代已經過去，取而代之的是 Microsoft ADO.NET 強大而又靈活的功能。我們的新武器就是 System.Data 名稱空間，它的特點是具有速度極快的 DataReader 和功能豐富的 DataSet，而且打包在一個面向對象的強大模型中。能夠使用這樣的工具一點都不奇怪。任何 3 層體系結構都依靠可靠的數據訪問層 (DAL) 將數據層與業務層完美地連接起來。高質量的 DAL 有助于改善代碼的重新使用，它是獲得高性能的關鍵，而且是完全透明的。
隨著工具的改進，我們的開發模式也發生了變化。告別 MoveNext 并不只是讓我們擺脫了繁瑣的語法，它還讓我們認識了斷開連接的數據，這種數據對我們開發應用程序的方式產生了深刻的影響。
因為我們已經熟悉了 DataReader（其行為與 RecordSet 非常類似），所以沒花多長時間就進一步開發出 DataAdapter、DataSet、DataTable 和 DataView。正是在開發這些新對象的過程中不斷得到磨煉的技能改變了我們的開發方式。斷開連接的數據使我們可以利用新的緩存技術，從而大大提高了應用程序的性能。這些類的功能使我們能夠編寫出更智能、更強大的函數，同時還能減少（有時候甚至是大大減少）常見活動所需的代碼數量。
有些情況下非常適合使用 DataSet，例如在設計原型、開發小型系統和支持實用程序時。但是，在企業系統中使用 DataSet 可能并不是最佳的解決方案，因為對企業系統來說，易于維護要比投入市場的時間更重要。本指南的目的就是探討一種適合處理此類工作的 DataSet 的替代解決方案，即：自定義實體與集合。盡管還存在其他替代解決方案，但它們都無法提供相同的功能或無法獲得更多的支持。我們的首要任務是了解 DataSet 的缺點，以便理解我們要解決的問題。
記住，每種解決方案都有優缺點，所以 DataSet 的缺點可能比自定義實體的缺點（我們也將進行討論）更容易讓您接受。您和您的團隊必須自己決定哪個解決方案更適合您的項目。記住要考慮解決方案的總成本，包括要求改變的實質所在以及生產后所需的時間比實際開發代碼的時間更長的可能性。最后請注意，我所說的 DataSet 并不是類型化的 DataSet，但它確實可以彌補非類型化的 DataSet 的一些缺點。
DataSet 存在的問題
缺少抽象
尋找替代解決方案的第一個也是最明顯的原因就是 DataSet 無法從數據庫結構中提取代碼。DataAdapter 可以很好地使您的代碼獨立于基礎數據庫供應商（Microsoft、Oracle、IBM 等），但不能抽象出數據庫的核心組件：表、列和關系。這些核心數據庫組件也是 DataSet 的核心組件。DataSet 和數據庫不僅共享通用組件，不幸的是，它們還共享架構。假定有下面這樣一個 Select 語句：
SELECT UserId, FirstName, LastName
FROM Users
我們知道這些值可以從 DataSet 中的 UserId、FirstName 和 LastName 這些 DataColumn 中獲得。
為什么會這么復雜？讓我們看一個基本的日常示例。首先我們有一個簡單的 DAL 函數：
//C#
public DataSet GetAllUsers() {
SqlConnection connection = new SqlConnection(CONNECTION_STRING);
SqlCommand command = new SqlCommand("GetUsers", connection);
command.CommandType = CommandType.StoredProcedure;
SqlDataAdapter da = new SqlDataAdapter(command);
try {
DataSet ds = new DataSet();
da.Fill(ds);
return ds;
}finally {
connection.Dispose();
command.Dispose();
da.Dispose();
}
}
然后我們有一個頁面，它使用重復器顯示所有用戶：
<HTML>
<body>
<form id="Form1" method="post" runat="server">
<asp:Repeater ID="users" Runat="server">
<ItemTemplate>
<%# DataBinder.eval_r(Container.DataItem, "FirstName") %>
<br>
</ItemTemplate>
</asp:Repeater>
</form>
</body>
</HTML>
<script runat="server">
public sub page_load
users.DataSource = GetAllUsers()
users.DataBind()
end sub
</script>
正如我們所看到的那樣，我們的 ASPX 頁面利用 DAL 函數 GetAllUsers 作為重復器的 DataSource。如果由于某種原因（為了性能而降級、為清楚起見而進行了標準化、要求發生了變化）導致數據庫架構發生變化，變化就會一直影響 ASPX，即影響使用“FirstName”列名的 Databinder.Eval 行。這將立刻在您腦海中產生一個危險信號：數據庫架構的變化會一直影響到 ASPX 代碼嗎？聽起來不太像 N 層，對嗎？
如果我們所要做的只是對列進行簡單的重命名，那么更改本例中的代碼并不復雜。但是，如果在許多地方都使用了 GetAllUsers，更糟糕的是，如果將其作為為無數用戶提供服務的 Web 服務，那又會怎么樣呢？怎樣才能輕松或安全地傳播更改？對于這個基本示例而言，存儲過程本身作為抽象層可能已經足夠；但是依賴存儲過程獲得除最基本的保護以外的功能則可能會在以后造成更大的問題。可以將此視為一種硬編碼；實質上，使用 DataSet 時，您可能需要在數據庫架構（不管使用列名稱還是序號位置）和應用層/業務層之間建立一個嚴格的連接。但愿以前的經驗（或邏輯）已經讓您了解到硬編碼對維護工作以及將來的開發產生的影響。
DataSet 無法提供適當抽象的另一個原因是它要求開發人員必須了解基礎架構。我們所說的不是基礎知識，而是關于列名稱、類型和關系的所有知識。去掉這個要求不僅使您的代碼不像我們看到的那樣容易中斷，還使代碼更易于編寫和維護。簡單地說：
Convert.ToInt32(ds.Tables[0].Rows[i]["userId"]);
不僅難于閱讀，而且需要非常熟悉列名稱及其類型。理想情況下，您的業務層不需要知道有關基礎數據庫、數據庫架構或 SQL 的任何內容。如果您像上述代碼字符串中那樣使用 DataSet（使用 CodeBehind 并不會有任何改善），您的業務層可能會很薄。
弱類型
DataSet 屬于弱類型，因此容易出錯，還可能會影響您的開發工作。這意味著無論何時從 DataSet 中檢索值，值都以 System.Object 的形式返回，您需要對這種值進行轉換。您面臨轉換可能會失敗的風險。不幸的是，失敗不是在編譯時發生，而是在運行時發生。另外，在處理弱類型的對象時，Microsoft Visual Studio.NET (VS.NET) 等工具對您的開發人員并沒有太大的幫助。前面我們說過需要深入了解構架的知識，就是指這個意思。我們再來看一個非常常見的示例：
'Visual Basic.NET
Dim userId As Integer =
?????? Convert.ToInt32(ds.Tables(0).Rows(0)("UserId"))
Dim userId As Integer = CInt(ds.Tables(0).Rows(0)("UserId"))
Dim userId As Integer = CInt(ds.Tables(0).Rows(0)(0))
//C#
int userId = Convert.ToInt32(ds.Tables[0].Rows[0]("UserId"));
這段代碼顯示了從 DataSet 中檢索值的可能方法——可能您的代碼中到處都需要檢索值（如果不進行轉換，而您使用的又是 Visual Basic .NET，您可能會使用 Option Strict Off 這樣的代碼，而這會給您帶來更大的麻煩。）
不幸的是，這些代碼中的每一行都可能會產生大量的運行時錯誤：
1.
轉換可能由于以下原因而失敗：
? 值可能為空。
? 開發人員可能對基礎數據類型判斷有誤（還是這個問題，即開發人員需要非常熟悉數據庫架構）。
? 如果您使用序號值，誰知道位置 X 處實際上是一個什么樣的列。
2.
ds.Tables(0) 可能返回一個空引用（如果 DAL 方法或存儲過程中有任何部分失敗）。
3.
“UserId”可能由于以下原因而是一個無效的列名稱：
? 可能已經更改了名稱。
? 可能不是由存儲過程返回的。
? 可能包含錯別字。
我們可以修改代碼并以更安全的方式編寫，即為 null/nothing 添加檢查，為轉換添加 try/catch，但這些對開發人員都沒有幫助。
更糟糕的是，正如我們前面所說，這不是抽象的。這意味著，每次要從 DataSet 中檢索 userId 時，您都將面臨上面提到的風險，或者需要對相同的保護性步驟進行重新編程（當然，實用程序功能可能會有助于降低風險）。弱類型對象將錯誤從設計時或編譯時（這時總能夠自動檢測并輕松修復錯誤）轉移到運行時（這時的錯誤可能會出現在生產過程中，而且更難查明）。
非面向對象
您不能僅僅因為 DataSet 是對象，而 C# 和 Visual Basic .NET 是面向對象 (OO) 的語言就能以面向對象的方式使用 DataSet。OO 編程的“hello world”是一個典型的 Person 類，該類又是 Employee 的子類。但 DataSet 并沒有使此類繼承或其他大多數 OO 技術成為可能（或者至少使它們變得自然/直觀）。Scott Hanselman 是類實體的堅決支持者，他做出了最好的解釋：
“DataSet 是一個對象，對嗎？但它并不是域對象，它不是一個‘蘋果’或‘桔子’，而是一個‘DataSet’類型的對象。DataSet 是一只碗（它知道支持數據存儲）。DataSet 是一個知道如何保存行和列的對象，它非常了解數據庫。但是，我不希望返回碗，我希望返回域對象，例如‘蘋果’。”1
DataSet 使數據之間保持一種關系，使它們更強大并且能夠在關系數據庫中方便地使用。不幸的是，這意味著您將失去 OO 的所有優點。
因為 DataSet 不能作為域對象，所以無法向它們添加功能。通常情況下，對象具有字段、屬性和方法，它們的行為針對的是類的實例。例如，您可能會將 Promote 或 CalcuateOvertimePay 函數與 User 對象相關聯，該對象可以通過 someUser.Promote() 或 someUser.CalculateOverTimePay() 安全地調用。因為無法向 DataSet 添加方法，所以您需要使用實用程序功能來處理弱類型對象，并且在整個代碼中包含硬編碼值的更多實例。您一般會以過程代碼結束，在過程代碼中，您要么不斷地從 DataSet 中獲取數據，要么以繁瑣的方式將它們存儲在本地變量中并向其他位置傳遞。兩種方法都有缺點，而且都沒有任何優點。
與 DataSet 相反的情況
如果您認為數據訪問層應返回 DataSet，您可能會漏掉一些重要的優點。其中一個原因是您可能正在使用一個較薄或不存在的業務層，除了其他問題外，它還限制了您進行抽象的能力。另外，因為您使用的是一般的預編譯解決方案，所以很難利用 OO 技術。最后，Visual Studio.NET 等工具使開發人員無法輕松地利用弱類型對象（例如 DataSet），因此降低了效率并且增加了出錯的可能性。
所有這些因素都以不同的方式對代碼的可維護性產生了直接的影響。缺乏抽象使功能改善和錯誤修復變得更復雜、更危險。您無法充分利用 OO 提供的代碼重新使用或可讀性方面的改進。當然還有一點，無論您的開發人員處理的是業務邏輯還是表示邏輯，他們都必須非常了解您的基礎數據結構。
返回頁首
自定義實體類
與 DataSet 有關的大多數問題都可以利用 OO 編程的豐富功能在定義明確的業務層中解決。實際上，我們希望獲得按照關系組織的數據（數據庫），并將數據作為對象（代碼）使用。這個概念就是，不是獲得保存汽車信息的 DataTable，而是獲得汽車對象（稱為自定義實體或域對象）。
在了解自定義實體之前，讓我們首先看一看我們將要面臨的挑戰。最明顯的挑戰就是所需代碼的數量。我們不是簡單地獲取數據并自動填充 DataSet，而是獲取數據并手動將數據映射到自定義實體（必須先創建好）。由于這是一項重復性的任務，我們可以使用代碼生成工具或 O/R 映射器（后文有詳細的介紹）來減輕工作量。更大的問題是將數據從關系世界映射到對象世界的具體過程。對于簡單的系統，映射通常是直接的，但是隨著復雜性的增加，這兩個世界之間的差異就會產生問題。例如，繼承在對象世界中是獲得代碼重新使用以及可維護性的重要技術。不幸的是，繼承對關系數據庫來說卻是一個陌生的概念。另外一個例子就是處理關系的方式不同：對象世界依靠維護單個對象的引用，而關系世界則是利用外鍵。
因為代碼的數量以及關系數據和對象之間的差異不斷增加，看起來這個方法并不太適合更復雜的系統，但事實正好相反。通過將各種問題隔離到一個層中，即映射過程（同樣可以自動化），復雜的系統也可以從此方法獲益。另外，此方法已經很常用，這意味著可以通過幾種已有的設計模式徹底解決增加的復雜性。前面討論的 DataSet 的缺點在復雜系統中將成倍擴大，最后您會得出這樣一個系統，它欠缺靈活應變能力的缺點恰好超出其構建的難度。
什么是自定義實體？
自定義實體是代表業務域的對象，因此，它們是業務層的基礎。如果您有一個用戶身份驗證組件（本指南通篇都使用該示例進行講解），您就可能具有 User 和 Role 對象。電子商務系統可能具有 Supplier 和 Merchandise 對象，而房地產公司則可能具有 House、Room 和 Address 對象。在您的代碼中，自定義實體只是一些類（實體和“類”之間具有非常密切的關系，就像在 OO 編程中使用的那樣）。一個典型的 User 類可能如下所示：
//C#
public class User {
#region "Fields and Properties"
private int userId;
private string userName;
private string password;
public int UserId {
get { return userId; }
set { userId = value; }
}
public string UserName {
get { return userName; }
set { userName = value; }
}
public string Password {
get { return password; }
set { password = value; }
}
#endregion
#region "Constructors"
public User() {}
public User(int id, string name, string password) {
this.UserId = id;
this.UserName = name;
this.Password = password;
}
#endregion
}
為什么能夠從它們獲益？
使用自定義實體獲得的主要好處來自這樣一個簡單的事實，即它們是完全受您控制的對象。具體而言，它們允許您：
? 利用繼承和封裝等 OO 技術。
? 添加自定義行為。
例如，我們的 User 類可以通過為其添加 UpdatePassword 函數而受益（我們可能會使用外部/實用程序函數對數據集執行此類操作，但會影響可讀性/維護性）。另外，它們屬于強類型，這表示我們可以獲得 IntelliSense 支持：
IntelliSense 圖 1：User 類的
最后，因為自定義實體為強類型，所以不太需要進行容易出錯的強制轉換：
Dim userId As Integer = user.UserId
'與
Dim userId As Integer =
????????? Convert.ToInt32(ds.Tables("users").Rows(0)("UserId"))
對象關系映射
正如前文所討論的那樣，此方法的
主要挑戰之一就是處理關系數據和對象之間的差異。因為我們的數據始終存儲在關系數據庫中，所以我們只能在這兩個世界之間架起一座橋梁。對于上文的 User 示例，我們可能希望在數據庫中建立一個如下所示的用戶表：
圖 2：User 的數據視圖
從這個關系架構映射到自定義實體是一個非常簡單的事情：
//C#
public User GetUser(int userId) {
SqlConnection connection = new SqlConnection(CONNECTION_STRING);
SqlCommand command = new SqlCommand("GetUserById", connection);
command.Parameters.Add("@UserId", SqlDbType.Int).Value = userId;
SqlDataReader dr = null;
try{
connection.Open();
dr = command.ExecuteReader(CommandBehavior.SingleRow);
if (dr.Read()){
User user = new User();
user.UserId = Convert.ToInt32(dr["UserId"]);
user.UserName = Convert.ToString(dr["UserName"]);
user.Password = Convert.ToString(dr["Password"]);
return user;
}
return null;
}finally{
if (dr != null && !dr.IsClosed){
dr.Close();
}
connection.Dispose();
command.Dispose();
}
}
我們仍然按照通常的方式設置連接和命令對象，但接著創建了 User 類的一個新實例并從 DataReader 中填充該實例。您仍然可以在此函數中使用 DataSet 并將其映射到您的自定義實體，但 DataSet 相對于 DataReader 的主要好處是前者提供了數據的斷開連接的視圖。在本例中，User 實例提供了斷開連接的視圖，使我們可以利用 DataReader 的速度。
等一下！您并沒有解決任何問題！
細心的讀者可能注意到我前面提到 DataSet 的問題之一是它們并非強類型，這導致效率降低并增加了出現運行時錯誤的可能性。它們還需要開發人員深入了解基礎數據結構。看一看上文的代碼，您可能會注意到這些問題依然存在。但請注意，我們已經將這些問題封裝到一個非常孤立的代碼區域內；這表示您的類實體的使用者（Web 界面、Web 服務使用者、Windows 表單）仍然完全沒有意識到這些問題。相反，使用 DataSet 可以將這些問題分散到整個代碼中。
改進
上文的代碼對顯示映射的基本概念很有用，但可以在兩個關鍵的方面進行改進。首先，我們需要提取并將代碼填充到其自己的函數中，因為代碼有可能會被重新使用：
//C#
public User PopulateUser(IDataRecord dr) {
User user = new User();
user.UserId = Convert.ToInt32(dr["UserId"]);
//檢查 NULL 的示例
if (dr["UserName"] != DBNull.Value){
user.UserName = Convert.ToString(dr["UserName"]);
}
user.Password = Convert.ToString(dr["Password"]);
return user;
}
第二個需要注意的事項是，我們不對映射函數使用 SqlDataReader，而是使用 IDataRecord。這是所有 DataReader 實現的接口。使用 IDataRecord 使我們的映射過程獨立于供應商。也就是說，我們可以使用上一個函數從 Access 數據庫中映射 User，即使它使用 OleDbDataReader 也可以。如果您將這個特定的方法與 Provider Model Design Pattern（鏈接 1、鏈接 2）結合使用，您的代碼就可以輕松地用于不同的數據庫提供程序。
最后，以上代碼說明了封裝的強大功能。處理 DataSet 中的 NULL 并非最簡單的事，因為每次提取值時都需要檢查它是否為 NULL。使用上述填充方法，我們在一個地方就輕松地解決了此問題，使我們的客戶無需處理它。
映射到何處？
關于此類數據訪問和映射函數的歸屬問題存在一些爭論，即究竟是作為獨立類的一部分，還是作為適當自定義實體的一部分。將所有用戶相關的任務（獲取數據、更新和映射）都作為 User 自定義實體的一部分當然很不錯。這在數據庫架構與自定義實體很相似時會很有用（比如在本例中）。隨著系統復雜性的增加，這兩個世界的差異開始顯現出來，將數據層和業務層明確分離對簡化維護有很大的幫助（我喜歡將其稱為數據訪問層）。將訪問和映射代碼放在其自己的層 (DAL) 上有一個副作用，即它為確保數據層與業務層的明確分離提供了一個嚴格的原則：
“永遠不要從 System.Data 返回類或從 DAL 返回子命名空間”
自定義集合
到目前為止，我們只了解了如何處理單個實體，但您經常需要處理多個對象。一個簡單的解決方案是將多個值存儲在一個一般的集合（例如 Arraylist）中。這并非最理想的解決方案，因為它又產生了與 DataSet 有關的一些問題，即：
? 它們不是強類型，并且
? 無法添加自定義行為。
最能滿足我們需求的解決方案是創建我們自己的自定義集合。幸虧 Microsoft .NET Framework 提供了一個專門為了此目的而繼承的類：CollectionBase。CollectionBase 的工作原理是，將所有類型的對象都存儲在專有 Arraylist 中，但是通過只接受特定類型（例如 User 對象）的方法來提供對這些專有集合的訪問。也就是說，將弱類型代碼封裝在強類型的 API 中。
雖然自定義集合可能看起來有很多代碼，但大多數都可以由代碼生成功能或通過剪切和粘貼方便地完成，并且通常只需要一次搜索和替換即可。讓我們看一看構成 User 類的自定義集合的不同部分：
//C#
public class UserCollection :CollectionBase {
public User this[int index] {
get {return (User)List[index];}
set {List[index] = value;}
}
public int Add(User value) {
return (List.Add(value));
}
public int IndexOf(User value) {
return (List.IndexOf(value));
}
public void Insert(int index, User value) {
List.Insert(index, value);
}
public void Remove(User value) {
List.Remove(value);
}
public bool Contains(User value) {
return (List.Contains(value));
}
}
通過實現 CollectionBase 可以完成更多任務，但上面的代碼代表了自定義集合所需的核心功能。觀察一下 Add 函數，可以看出我們只是簡單地將對 List.Add（它是一個 Arraylist）的調用封裝到僅允許 User 對象的函數中。
映射自定義集合
將我們的關系數據映射到自定義集合的過程與我們對自定義實體執行的過程非常相似。我們不再創建一個實體并將其返回，而是將該實體添加到集合中并循環到下一個：
//C#
public UserCollection GetAllUsers() {
SqlConnection connection = new SqlConnection(CONNECTION_STRING);
SqlCommand command =new SqlCommand("GetAllUsers", connection);
SqlDataReader dr = null;
try{
connection.Open();
dr = command.ExecuteReader(CommandBehavior.SingleResult);
UserCollection users = new UserCollection();
while (dr.Read()){
users.Add(PopulateUser(dr));
}
return users;
}finally{
if (dr != null && !dr.IsClosed){
dr.Close();
}
connection.Dispose();
command.Dispose();
}
}
我們從數據庫中獲得數據、創建自定義集合，然后通過在結果中循環來創建每個 User 對象并將其添加到集合中。同樣要注意 PopulateUser 映射函數是如何重新使用的。
添加自定義行為
在討論自定義實體時，我們只是泛泛地提到可以將自定義行為添加到類中。您向實體中添加的功能類型很大程度上取決于您要實現的業務邏輯的類型，但您可能希望在自定義集合中實現某些常見的功能。一個示例就是返回一個基于某個鍵的實體，例如基于 userId 的用戶：
//C#
public User FindUserById(int userId) {
foreach (User user in List) {
if (user.UserId == userId){
return user;
}
}
return null;
}
另一個示例可能是返回基于特定標準（例如部分用戶名）的用戶子集：
//C#
public UserCollection FindMatchingUsers(string search) {
if (search == null){
throw new ArgumentNullException("search cannot be null");
}
UserCollection matchingUsers = new UserCollection();
foreach (User user in List) {
string userName = user.UserName;
if (userName != null && userName.StartsWith(search)){
matchingUsers.Add(user);
}
}
return matchingUsers;
}
可以通過 DataTable.Select 以相同的方式使用 DataSets。需要說明的重要一點是，盡管創建自己的功能使您可以完全控制您的代碼，但 Select 方法為完成同樣的操作提供了一個非常方便且不需要編寫代碼的方法。但另一方面，Select 需要開發人員了解基礎數據庫，而且它不是強類型。
綁定自定義集合
我們看到的第一個示例是將 DataSet 綁定到 ASP.NET 控件。考慮到它很普通，您會高興地發現自定義集合綁定同樣很簡單（這是因為 CollectionBase 實現了用于綁定的 Ilist）。自定義集合可以作為任何控件的 DataSource，而 DataBinder.Eval 只能像您使用 DataSet 那樣使用：
//C#
UserCollection users = DAL.GetAllUsers();
repeater.DataSource = users;
repeater.DataBind();
<!-- HTML -->
<asp:Repeater onItemDataBound="r_IDB" ID="repeater" Runat="server">
<ItemTemplate>
<asp:Label ID="userName" Runat="server">
<%# DataBinder.eval_r(Container.DataItem, "UserName") %><br>
</asp:Label>
</ItemTemplate>
</asp:Repeater>
您可以不使用列名稱作為 DataBinder.Eval 的第二個參數，而指定您希望顯示的屬性名稱，在本例中為 UserName。
對于在許多數據綁定控件提供的 OnItemDataBound 或 OnItemCreated 中執行處理的人來說，您可能會將 e.Item.DataItem 強制轉換成 DataRowView。當綁定到自定義集合時，e.Item.DataItem 則被強制轉換成自定義實體，在我們的示例中為 User 類：
//C#
protected void r_ItemDataBound(object sender, RepeaterItemEventArgs e) {
ListItemType type = e.Item.ItemType;
if (type == ListItemType.AlternatingItem ||
???? type == ListItemType.Item){
Label ul = (Label)e.Item.FindControl("userName");
User currentUser = (User)e.Item.DataItem;
if (!PasswordUtility.PasswordIsSecure(currentUser.Password)){
ul.ForeColor = Color.Red;
}
}
}
返回頁首
管理關系
即使在最簡單的系統中，實體之間也存在關系。對于關系數據庫，可以通過外鍵維護關系；而使用對象時，關系只是對另一個對象的引用。例如，根據我們前面的示例，User 對象完全可以具有一個 Role：
//C#
public class User {
private Role role;
public Role Role {
get {return role;}
set {role = value;}
}
}
或者一個 Role 集合：
//C#
public class User {
private RoleCollection roles;
public RoleCollection Roles {
get {
if (roles == null){
roles = new RoleCollection();
}
return roles;
}
}
}
在這兩個示例中，我們有一個虛構的 Role 類或 RoleCollection 類，它們就是類似于 User 和 UserCollection 類的其他自定義實體或集合類。
映射關系
真正的問題在于如何映射關系。讓我們看一個簡單的示例，我們希望根據 userId 及其角色來檢索一個用戶。首先，我們看一看關系模型：
圖 3：User 與 Role 之間的關系
這里，我們看到了一個 User 表和一個 Role 表，我們可以將這兩個表都以直觀的方式映射到自定義實體。我們還有一個 UserRoleJoin 表，它代表了 User 與 Role 之間的多對多關系。
然后，我們使用存儲過程來獲取兩個單獨的結果：第一個代表 User，第二個代表該用戶的 Role：
CREATE PROCEDURE GetUserById(
@UserId INT
)AS
SELECT UserId, UserName, [Password]
FROM Users
WHERE UserId = @UserID
SELECT R.RoleId, R.[Name], R.Code
FROM Roles R INNER JOIN
UserRoleJoin URJ ON R.RoleId = URJ.RoleId
WHERE URJ.UserId = @UserId
最后，我們從關系模型映射到對象模型：
//C#
public User GetUserById(int userId) {
SqlConnection connection = new SqlConnection(CONNECTION_STRING);
SqlCommand command = new SqlCommand("GetUserById", connection);
command.Parameters.Add("@UserId", SqlDbType.Int).Value = userId;
SqlDataReader dr = null;
try{
connection.Open();
dr = command.ExecuteReader();
User user = null;
if (dr.Read()){
user = PopulateUser(dr);
dr.NextResult();
while(dr.Read()){
user.Roles.Add(PopulateRole(dr));
}
}
return user;
}finally{
if (dr != null && !dr.IsClosed){
dr.Close();
}
connection.Dispose();
command.Dispose();
}
}
User 實例即被創建和填充；我們轉移到下一個結果/選擇并進行循環，填充 Role 并將它們添加到 User 類的 RolesCollection 屬性中。
高級內容
本指南的目的是介紹自定義實體與集合的概念及使用。使用自定義實體是業界廣泛采用的做法，因此，也就產生了同樣多的模式以處理各種情況。設計模式具有優勢的原因有很多。首先，在處理具體的情況時，您可能不是第一次碰到某個給定的問題。設計模式使您可以重新使用給定問題的已經過嘗試和測試的解決方案（雖然設計模式并不意味著全盤照抄，但它們幾乎總是能夠為解決方案提供一個可靠的基礎）。相應地，這使您對系統隨著復雜性增加而進行縮放的能力充滿了信心，不僅因為它是一個廣泛使用的方法，還因為它具有詳盡的記錄。設計模式還為您提供了一個通用的詞匯表，使知識的傳播和傳授更容易實現。
不能說設計模式只適用于自定義實體，實際上許多設計模式都并非如此。但是，如果您找機會試一下，您可能會驚喜地發現許多記載詳盡的模式確實適用于自定義實體和映射過程。
最后這一部分專門介紹大型或較復雜的系統可能會碰到的一些高級情況。因為大多數主題都可能值得您單獨學習，所以我會盡量為您提供一些入門資料。
Martin Fowler 的 Patterns of Enterprise Application Architecture 就是一個很好的入門材料，它不僅可以作為常見設計模式的優秀參考（具有詳細的解釋和大量的示例代碼），而且它的前 100 頁確實可以讓您透徹地了解整個概念。另外，Fowler 還提供了一個聯機模式目錄，它對于已經熟悉概念但需要一個便利參考的人士很有用。
并發
前面的示例介紹的都是從數據庫中提取數據并根據這些數據創建對象。總體而言，更新、刪除和插入數據等操作是很直觀的。我們的業務層負責創建對象、將對象傳遞給數據訪問層，然后讓數據訪問層處理對象世界與關系世界之間的映射。例如：
//C#
public void UpdateUser(User user) {
SqlConnection connection = new SqlConnection(CONNECTION_STRING);
SqlCommand command = new SqlCommand("UpdateUser", connection);
// 可以借助可重新使用的函數對此進行反向映射
command.Parameters.Add("@UserId", SqlDbType.Int);
command.Parameters[0].Value = user.UserId;
command.Parameters.Add("@Password", SqlDbType.VarChar, 64);
command.Parameters[1].Value = user.Password;
command.Parameters.Add("@UserName", SqlDbType.VarChar, 128);
command.Parameters[2].Value = user.UserName;
try{
connection.Open();
command.ExecuteNonQuery();
}finally{
connection.Dispose();
command.Dispose();
}
}
但在處理并發時就不那么直觀了，也就是說，當兩個用戶試圖同時更新相同的數據時會出現什么情況呢？默認的行為（如果您沒有執行任何操作）是最后提交數據的人將覆蓋以前所有的工作。這可能不是理想的情況，因為一個用戶的工作將在未獲得任何提示的情況下被覆蓋。要完全避免所有沖突，一種方法就是使用消極的并發技術；但此方法需要具有某種鎖定機制，這可能很難通過可縮放的方式實現。替代方法就是使用積極的并發技術。讓第一個提交的用戶控制并通知后面的用戶是通常采取的更溫和、更用戶友好的方法。這可以通過某種行版本控制（例如時間戳）來實現。
參考資料：
? Introduction to Data Concurrency in ADO.NET
? CSLA.NET's concurrency techniques
? Unit of Work design pattern
? Optimistic offline lock design pattern
? Pessimistic offline lock design pattern
性能
與合理的靈活性和功能問題相對的是，我們經常擔心細小的性能差異。盡管性能的確很重要，但提供適用于一切情況而不是最簡單情況的通用原則通常很難。例如，將自定義集合與 DataSet 相比，哪個更快？使用自定義集合，您可以大量使用 DataReader，這是從數據庫中提取數據的較快方式。但答案實際上取決于您使用它們的方式以及處理的數據類型，所以一般性的說明沒有任何用。更重要的一點是要認識到，不管您能節省多少處理時間，與維護性方面的差異相比都可能微不足道。
當然，并不是說您不可能找到一個既具有高性能又可維護的解決方案。雖然我強調說答案實際上取決于您的使用方式，但的確有一些模式可以幫助您最大程度地提高性能。但是，首先要知道的是自定義實體與集合緩存以及 DataSet，并且能夠利用相同的機制（類似于 HttpCache）。DataSet 的優勢之一是它能夠編寫 Select 語句，以便只獲取所需的信息。使用自定義實體時，您常常感到不得不填充整個實體以及子實體。例如，如果要通過 DataSet 顯示一個 Organization 列表，您可以只提取 OganizationId、Name 和 Address 并將其綁定到重復器。使用自定義實體時，我總覺得還需要獲取所有其他的 Organization 信息，如果該組織通過了 ISO 認證，則可能是一個位標記，即所有員工、其他聯系信息等的集合。可能其他人沒有碰到這個大難題，但幸運的是，如果我們愿意，我們可以對自定義實體進行很好的控制。最常用的方法是使用一種延遲加載模式，它只在首次需要時獲取信息（可以很好地封裝在屬性中）。這種對各個屬性的控制提供了通過其他方式無法輕易獲得的巨大靈活性（請想象一下在 DataColumn 級別執行類似操作的情況）。
參考資料：
? Lazy Load 設計模式
? CSLA.NET lazy load
排序與篩選
雖然 DataView 對排序和篩選的內置支持需要您了解有關 SQL 和基礎數據結構的知識，但它提供的方便確實是自定義集合所不具備的。我們仍然可以排序和篩選，但首先需要編寫功能。因為技術不一定是最先進的，所以代碼的完整描述不屬于本節要討論的范圍。大多數技術都很相似，例如使用篩選器類篩選集合以及使用比較器類進行排序，我認為不存在固定的模式。但是，的確存在一些參考資料：
? Generic sort function
? Sorting & Filtering Custom Collections 教程
代碼生成
解決概念上的障礙后，自定義實體與集合的主要缺點就是靈活性、抽象和維護性差所導致的代碼數量的增加。實際上，您可能會認為我所說的維護成本和錯誤的降低這一切都抵不上代碼的增加。雖然這一觀點是成立的（同樣，因為任何解決方案都不是完美無缺的），但可以通過設計模式和框架（例如 CSLA.NET）大大緩解此問題。代碼生成工具與模式和框架完全不同，這些工具可以大大降低您實際需要編寫的代碼數量。本指南最初打算專門辟出一節詳細介紹代碼生成工具，特別是流行的免費 CodeSmith；但現有的許多參考資料都可能超出了我自己對該產品的認識。
在繼續之前，我認識到代碼生成聽起來像天方夜譚一樣。但經過正確的使用和理解后，它的確是您工具包中不可缺少的一個強大的武器，即使您沒有處理自定義實體也是如此。雖然代碼生成的確不僅僅適用于自定義實體，但很多都是專為自定義實體而設計的。原因很簡單：自定義實體需要大量重復代碼。
簡言之，代碼生成是如何工作的？構想聽起來好像遙不可及甚至反而會降低效率，但您基本上通過編寫代碼（模板）來生成代碼。例如，CodeSmith 附帶了許多強大的類，使您可以連接到數據庫并獲取所有屬性：表、列（類型、大小等）和關系。獲得這些信息后，我們前面討論的大部分工作都可以自動完成。例如，開發人員可以選擇一個表，然后使用正確的模板自動創建自定義實體（帶有正確的字段、屬性和構造函數），并獲得映射函數、自定義集合以及基本的選擇、插入、更新和刪除功能。甚至還可以更進一步，實現排序、篩選以及我們提到的其他高級功能。
CodeSmith 還附帶了許多現成的模板，可以作為很好的學習資料。最后，CodeSmith 還為實現 CSLA.NET 框架提供了許多模板。我最初只花了幾個小時來學習基本概念、熟悉 CodeSmith 的功能，但它為我節省的時間已經多得無法計算了。另外，如果所有的開發人員都使用相同的模板，代碼的高度一致性將使您能夠輕松地繼續其他人的工作。
參考資料：
? Code Generation with CodeSmith
? CodeSmith 主頁
O/R 映射器
即使因為對 O/R 映射器知之甚少使我不敢隨便對它們發表議論，但它們自身的潛在價值使其不容忽視。代碼生成器生成基于模板的代碼，供您復制并粘貼到您自己的源代碼中，而 O/R 映射器則在運行時通過某種配置機制動態生成代碼。例如，在 XML 文件中，您可以指定某個表的列 X 映射到某個實體的屬性 Y。您仍然需要創建自定義實體，但是集合、映射和其他數據訪問函數（包括存儲過程）都是動態創建的。從理論上講，O/R 映射器幾乎可以完全解決自定義實體存在的問題。隨著關系世界和對象世界的差異越來越明顯以及映射過程越來越復雜，O/R 映射器的價值就變得越發不可限量了。O/R 映射器的兩個缺點據說就是不夠安全和性能較差（至少在 .NET 環境中是這樣）。根據我所閱讀的資料，我確信它們并不是不夠安全，雖然在有些情況下性能較差，但在另外一些情況下卻表現突出。O/R 映射器并不適合所有情況，但如果您要處理復雜的系統，則應嘗試一下它們的功能。
參考資料：
? Mapper 設計模式
? Data Mapper 設計模式
? Wilson ORMapper
? Frans Bouma 關于 O/R 映射的帖子
? LLBGenPro
? NHibernate
.NET Framework 2.0 的功能
即將面世的 .NET Framework 2.0 版將改變我們在本指南中討論的一些實施細節。這些改變將減少支持自定義實體所需的代碼數量，并有助于處理映射問題。
泛型
議論頗多的泛型之所以存在，主要原因之一就是為了向開發人員提供現成的強類型的集合。我們避開 Arraylist 等現有集合是因為它們屬于弱類型。泛型提供了與當前集合同樣的方便性，而且它們屬于強類型。這是通過在聲明時指定類型來實現的。例如，我們可以替換 UserCollection 而不需要增加代碼，然后只需創建一個 List<T> 泛型的新實例并指定我們的 User 類即可：
'Visual Basic .NET
Dim users as new IList(of User)
//C#
IList<User> users = new IList<user>();
聲明后，我們的 user 集合就只能處理 User 類型的對象了，這為我們提供了編譯時檢查和優化的所有優點。
參考資料：
? Introducing .NET Generics
? An Introduction to C# Generics
可以為空的類型
可以為空的類型實際上就是由于其他原因而非上述原因而使用的泛型。處理數據庫時面臨的挑戰之一就是正確一致地處理支持 NULL 的列。在處理字符串和其他類（稱為引用類型）時，您只需為代碼中的某個變量指定 nothing/null：
'Visual Basic .NET
if dr("UserName") Is DBNull.Value Then
user.UserName = nothing
End If
//C#
if (dr["UserName"] == DBNull.Value){
user.UserName = null;
}
也可以什么都不做（默認情況下，引用類型為 nothing/null）。這對值類型（例如整數、布爾值、小數等）并不完全一樣。您當然也可以為這些值指定 nothing/null，但這樣將會指定一個默認值。如果您只聲明整數，或者為其指定 nothing/null，變量的值實際上將為 0。這使其很難映射回數據庫：值究竟為 0 還是 null？可以為空的類型允許值類型具有具體的值或者為空，從而解決了這個問題。例如，如果我們要在 userId 列中支持 null 值（并不是很符合實際情況），我們會首先將 userId 字段和對應的屬性聲明為可以為空的類型：
//C#
private Nullable<int> userId;
public Nullable<int> UserId {
get { return userId; }
set { userId = value; }
}
然后利用 HasValue 屬性判斷是否指定了 nothing/null：
//C#
if (UserId.HasValue) {
return UserId.Value;
} else {
return DBNull.Value;
}
參考資料：
? Nullable types in C#
? Nullable types in VB.NET
迭代程序
我們前面討論的 UserCollection 示例只展示了自定義集合中可能需要的基本功能。有一個操作無法通過所提供的實現來完成，即通過一個 foreach 循環在集合中循環。要完成此操作，您的自定義集合必須具有實現 IEnumerable 接口的枚舉數支持類。這是一個非常直觀且重復性較強的過程，但卻引入了更多的代碼。C# 2.0 引入了新的 yield 關鍵字來為您處理此接口的實現細節。Visual Basic .NET 中當前沒有與新的 yield 關鍵字等效的關鍵字。
參考資料：
? What's new In C# 2.0 - Iterators
? C# Iterators
小結
請勿輕率地做出向自定義實體與集合轉換的決定。這里有許多需要考慮的因素。例如，您對 OO 概念的熟悉程度、可用來熟悉新方法的時間以及您打算部署它的環境。雖然總體上它們有很大的優點，但并不一定適合您的特定情況。即使適合您的情況，它們的缺點也可能會打消您使用它們的念頭。還要記住有許多可替代的解決方案。Jimmy Nilsson 在他的 Choosing Data Containers for .NET 中概述了其中的某些替代方案，此專欄系列包括 5 部分。
自定義實體使您獲得了面向對象的編程的豐富功能，并幫助您構建了可靠、可維護的 N 層體系結構的框架。本指南的目的之一是讓您從構成系統的業務實體，而不是一般的 DataSet 和 DataTable 的角度來考慮您的系統。我們還討論了一些關鍵的問題，不管您選擇的途徑（即設計模式）、對象世界與關系世界的差異以及 N 層體系結構是什么，您都應注意這些問題。請記住，您之前花費的時間會在系統的整個生命周期內為您帶來更多的回報。
#c#專欄總結
- 上一篇： PHP Warning: date()
- 下一篇： 就算是蜗牛，也有爬到树顶的那一天！～