本篇的話題主要如下：
問題提出
設計方案
問題提出
數據訪問層(DAL)的目標創建一些以便業務層來調用的類和方法。我們之前總是用GridView來綁定 DataSet和DataReader，但是在稍微大點的項目開發中DAL不能直接和用戶
界面打交道。
一般來說，DAL是用來和數據庫和BLL打交道的，也就是處理BLL和數據庫的中間。數據以什麼形式在 DAL和BLL之前傳遞有很多的爭論。不同的人有不同的意見，數據傳遞的形式有：DataSet，強類型的 DataSet,DataReader,自定義實體。在介紹Ling to Sql之後，大家心裡會有清晰的答案。在以前的開發中 ，我們一般是采用ADO.NET來和數據庫打交道，那麼就需要我們的開發人員對ADO.NET有一定的比較深入的 了解，但是當我們用Linq to Sql之後，我們可以很方便的使用DataContext來與數據庫拉打交道，而不 需要我們懂得很多的ADO.NET的知識，但是在Linq to Sql的背後還是在采用ADO.NET來和數據庫交互的。
還有就是事務處理的問題。關於事務的概念，相信大家都清楚，我也不贅述了。事務處理在什麼地方 實現有如下意見：在存儲過程中直接用SQL語句來寫；在DAL層處理，
在BLL層處理。當然，每一種的選擇都有各自的理由和利弊。還有一點要注意的是：不要把事務處理的 代碼到處寫，如在DAL層中寫一點，在BLL中寫一點。
設計方案
在設計方案中實際上就是提供幾個選擇來解決之前我們提出的問題。以下就是兩個選擇：
1.DAL只要是執行CRUD操作，CRUD是就是：Create,Read,Update,Delete.在.NET Framwework中提供了 很多和數據庫打交道的ADO.NET類和方法，如
SqlConnection,SqlCommand,SqlCommand.ExecuteNonQuery()等，用過ADO.NET的朋友應該清楚這些常 用的類，我這裡也不羅嗦。
2.SqlHelper
用過ADO.NET的朋友應該知道，在我們開發過程中，很多時候寫ADO.NET代碼的時候，代碼結構和功能 都是大同小異的，所以基於此，微軟就開發了Microsoft Data Access Application Block，只要我們調 用其中的一些方法，傳入一些參數就行了，不需要我們再去寫那些繁瑣的ADO.NET代碼，因為這個數據訪 問塊都已經封裝好了。其中一個最重要的類就是SqlHelper.這個類是個靜態類，提供了很多的方法，如下 ：
ExecuteNonQuery
ExecuteDataset
ExecuteReader
ExecuteScalar
FillDataset
