一旦你得到了適當的安全組件，你就做好准備研究你的數據訪問方法了。人們在這方面常犯的錯誤就是在顯示層開發所有的東西，包括你的商業邏輯和數據訪問組件。這種開發就導致了很難維護的像意大利面條一樣的代碼（見資源）。它也使改變數據庫的計劃或者改變到一個全新的數據庫變得很難、很昂貴，因為你必須找到散布在你的應用程序中的所有的單獨的數據訪問調用指令。用四個層來構建你的企業級的應用程序——顯示層、工作流層、商業層和數據訪問層——可以使應用程序更容易維護、更具擴展性。
關於這個話題，我將重點講述數據訪問層。應用程序需要將數據訪問層同商業對象明顯分離開。你不想讓SQL語句散布在從顯示層到商業層的所有代碼中。這些層不需要知道數據是如何得到的，從哪裡得到的。
Microsoft包含兩個新的對象——Dataset和DataReader——它們作為ADO.NET的一部分來分離各個層。Dataset對象對於一個不連接的應用程序模式是很有用的，而DataReader對象則用於連接的應用程序。然而，這些對象都有一個缺點：當你訪問屬性的值時，它們或者通過名字或者通過列號來查找。在通過列的名字訪問數據的情況下，如果在這些名字中有一個typo，在編譯時就不會被檢測出來。當列名散布在你的代碼中時，就很難在以後改變它們的名字了。如果你通過列號來訪問數據，代碼更難讀，而且你需要知道列在Dataset或DataReader中出現的順序。
運用Strongly Typed Datasets
強類型（strongly typed) datasets解決了這個問題，但你不能總用Dataset對象。當你運用Dataset對象時，它把所有記錄都讀進內存中，在大量的應用程序中，服務器資源會用盡。但如果用DataReader，就沒有一個等同於strongly typed Row的對象。一種方法就是反復運用Dataset和DataReader，這樣會形成強類型的對象，是很理想的。
我用的一種方法就是對每個表用一個Proxy對象和一個Domain對象。Proxy對象包含SQL語句或存儲過程調用指令來得到或保存域對象。Domain對象包含屬性來體現表的特性。商業邏輯組件與Proxy對象交互，並在Domain對象上執行商業邏輯。這種方法為Proxy對象限制了SQL語句或過程名字的內容。它提供了一個統一的數據訪問策略，提高了應用程序代碼的可讀性，減少了運行時的錯誤，並提供了靈活性，如果它有必要轉換到一個不同的數據庫層的話（見圖1）。
圖1. 顯示各個層
我們有必要探討一下關於Proxy對象更多的細節問題。一個引起人們爭議的問題就是在Proxy對象中是運用SQL語句還是運用存儲過程調用。運用存儲過程比SQL語句更有效。因此一些公司更喜歡用存儲過程，但你應該選用更適合你公司的方法。不管你采用什麼方法，避免割裂存儲過程和商業邏輯組件之間的商業邏輯。我喜歡把商業邏輯保存在商業對象中。作為例子，我提供了一個C#代碼列表，它顯示了一個Authors表的Proxy和Domain類（見列表2）。
