壹般的，我們把系統所需要的數據放在數據庫中。而顯示給用戶的頁面中使用的數據是通過讀取數據庫並進壹步處理得到的。
而數據庫中的數據是結構的。
我們需要的.net編程中的數據時面向對象整合了的。
故：我們需要壹種機制，可以把數據庫中的結構性的數據轉換為面向對象的數據。於是就出現了系統架構中常見的3層架構：
底層：DAL（Data Access Layer，數據訪問層）
中間：BLL (Bussiness Logic Layer，業務邏輯層）
頂層：UI層~
DAL中，我們使用實體類完成對數據庫表的封裝：
例如：我們構建壹個文章管理系統。需要以下表
[Articles] [Categories] [Comments]
以[Articles]為例，包含的字段：
[ArticleID] [Title] [Content] [AddedBy] [AddedDate]
DAL層對應的實體類為[ArticleDetails]
包含以下屬性[ArticleID] [Title].......等5個屬性，以此對應表的5個字段。
對應DB中的3個表，我們有3個實體類。
創建類SqlArticlesProvider 來完成對DB的操作的封裝。
通常每個方法封裝壹個存儲過程~
例如：GetArticles(int categoryID)方法中。
我們連接DB，調用SP，並將返回的DataReader封裝到實體類集合List<ArticleDetails>中。以用於傳輸給BLL層。
BLL層：
之中的類稱為域對象。有[Article] [Category] [Comment]
這裏的每個類就是我們傳統OOP中的類。
每個對象包含描述自己的屬性和可執行行為的方法。
UI層，直接調用BLL層的類以獲取數據，並通過數據綁定控件顯示的頁面等~
說的有點亂。。。光這麽著說確實不是特別充分。。
而且真正實踐編程起來，比這個復雜。。
三層架構之後的系統更易於維護。變更底層數據存儲，需要改動的地方非常少。
故，主要是用於大中型系統架構。
而且現在推出LINQ後，對編碼量也降低了。但是單獨學習LINQ，時間也不會少。
如果不要LINQ的話，還是有很多工具代碼可以幫助自動的構建壹些類的~