dataset與sqldataadapter物件是微軟在ado.net中推出的新一代的資料訪問方式，有些情況下非常適合使用 dataset，例如在設計原型、開發小型系統和支援實用程式時。但是，在企業系統中使用 dataset 可能並不是最佳的解決方案，因為對企業系統來說，易於維護要比投入市場的時間更重要。因此在這裡我們** dataset 的一種替代解決方案，即：自定義實體與集合
一、dataset 存在的問題
問題一：硬編碼問題
dataset 和資料庫不僅共享資料，不幸的是，它們還共享架構。
如：(資料訪問的c#**：
public dataset getallusers()
頁面**：
在這個例子中我們可以看到，在aspx頁面中直接繫結了列名"fistname"，如果資料庫的結構發生變化（闢如更改列名）,那這種變化會直接從資料庫影響到我們的用介面層（雖然這種**修改不麻煩）。這樣還像「n層」結構嗎？從某種程式上看，我認為這是一種硬編碼。在大型軟體中使用這種型式開發，會給將來的維護帶來很大的麻煩的。
另外，這種編碼方式還必須使使用者層知道資料庫的結構，當然也有人提出了使用強型別dataset和常量解決這個問題。但這裡的編碼語法會使程式設計師很煩。如：ds.tables[0].rows[i]["userid"].tostring()不僅難於閱讀，而且需要非常熟悉列名稱及其型別。如果像這樣使用 dataset，業務層可能會很薄弱或很複雜。
問題二：弱型別的問題
dataset的資料表中的值都以 system.object 的形式返回，需要對這種值進行轉換，但轉換可能會失敗的風險（如：空值轉換，型別不匹配轉換，識別符號不正確等），不幸的是，失敗不是在編譯時發生，而是在執行時發生。另外，在轉換的時候，我們可能會遇到拆箱和裝箱的操作這種操作會比較耗費資源，降低軟體效能。
問題三：物件導向的桎梏
dataset雖然是個物件，但是這個物件還是從資料庫中的二維關係表演化過來的，我們的乙個實體物件在dataset中卻變成資料表中的一條記錄，而物件與物件的關係卻變成資料表與資料表之間的資料關係(datarelation)。而我們物件導向的思想是在程式**中模擬現實中的物件來構建程式中的物件的屬性和方法，然後建立程式物件之間的引用與派生關係。
正因如此，我們的程式**很難如實反應我們現實生活中的物件及物件與物件之間的聯絡。
所以說dataset這個東西能很好地理解資料庫，但不能很好地理解我們的生活。
二、自定義實體類：(
自定義實體類是我們根據現實生活中的物件抽象出來的類，它的物件能很好地反應我們的生活。它很好地利用繼承和封裝等 oo 技術。
如：public class user
set
}public string password
set
}public user() {}
public user(string name, string password)
}三、泛型集合list
list這個泛型集合所在的命名空間是：system.collections.generic，它是乙個強型別的集合，它還提供了一系列的集合操作方法，如新增、刪除、檢索、排序等。
其中的"t"中個型別「代位符」，當我們例項化list的時候，會根據"t"的值，控制我們list只儲存相應型別的資料。
如：listlist = new list();
這句話就生成乙個集合list，該集合中的每乙個元素必須是user資料型別，如果試圖把其它資料型別新增到我們的list集合中去會發生編譯異常。另外在取得list集合中的某個元素的時候，也不必去進行強制轉換，因為它儲存進去的就是user型別。
如：public listgetuser(string username)
conn.close();
return list;
}在vs2005中我們的gridview和datalist都可以繫結到我們的實體類泛型集合上，就像使用dataset繫結一樣方便。)
在泛型集合中有的方法sort()可以對裡面的實體類進行排序，但是如果僅簡單使用sort()進行排序的話會產生異常。因為list中所儲存的是乙個實體物件，究竟按照哪個實體屬性進行排序list物件現在並不知道。除非我們實體類實現icomparable介面。
icomparable介面中有個方法"int compareto(t)"需要我們實現，在該方法中編寫**，把當前物件與t物件相關屬性值的進行對比，並根據對比的結果返回-1,1,0三個值，以做為list物件對其內部實體類物件進行排序的依據。
如：public class user : icomparable
set
}public string password
set
}public user() {}
public user(string name, string password)
public int compareto(user obj)
else if(this.username < obj.username)
else}}
四、實體類之間的關係
對於關聯式資料庫，可以通過外來鍵維護關係。實體之間也存在關係，而在實體類中，關係則體現為乙個實體類對另乙個物件的引用。(
如：public class role : icomparable
set}
public string rolename
set}
public role(){}
public role(string roleid,string rolename)
public int compareto(role obj)
}public class user : icomparable
set
}public string password
set
}public listroles
set}
public user() {}
public user(string name, string password)
public int compareto(user obj)
else if(this.username < obj.username)
else}}
資料訪問類：
//角色資料訪問類
public class roleda
//根據角色代號返回角色實體物件
public roledata select(string roleid)
conn.close();
return rd;}}
//使用者角色關係資料訪問類
public class userinroleda
//根據使用者名稱查詢該使用者的角色列表
public listselect(string username)
conn.close();
return list;}}
//使用者資料訪問類
public class userda
//根據使用者名稱返回使用者實體對)
public userdata select(string username)
conn.close();
return user;}}
客戶端**：
userdata user = new userda().select("fred l. mannering");
response.write("username:"+user.username+"
");response.write("password:"+user.password+"
");foreach (roledata role in user.roles)
執行結果：
username:fred l. mannering
password:aaa
>>role:r002-manager
>>role:r003-employee
自定義實體類使您獲得了物件導向的程式設計的豐富功能，並幫助您構建了可靠、可維護的 n 層體系結構的框架，它也是目前業界所普遍採用的實現方式。
dataset和實體類 之間的轉換
dataset轉實體類 public static ilistfillmodel dataset ds foreach datarow dr in ds.tables 0 rows l.add model return l 將實體類轉換成datatable public static datatab...
實體類與電梯
我們先假設一種情況，乙個開發商想蓋一座大樓 假設30層吧 先要弄乙個設計圖紙呀，沒有設計圖紙怎麼蓋樓呢？設計圖紙的其他部分我們就先不管了，只看看電梯的這一塊的情況。一開始要選用電梯公司a的電梯，於是設計圖就根據a的電梯設計電梯間。圖紙設計完了，開始施工，一切都很順利，很快大樓就蓋起來了，大家都很高興...
「表單控制項」與「實體類」
或許這是一種廣告，但是不得不在這裡寫一下，表單與實體類之間我們經常會做一堆的事情賦值和取值，需要不斷的型別轉換，寫sql語句或者是要和實體類賦值 以及測試等等。這對簡單的新增和刪除 修改來說很即浪費人力，又浪費時間！然而現在，我在keelkit 實現了自動賦值！演示如下 keel.dbhelperd...