似乎大家都知道你應該在GUI，業務邏輯和數據訪問之間有明確的區別。我最近與一位吹噓總是擁有一個乾淨的數據訪問層的程序員交談。我看了這段代碼，結果發現他的數據訪問層只是一個包裝了幾個SQL方法的小類（如ExecuteNonQuery和ExecuteReader）。事實證明，在他的ASP.NET代碼頁面後面，他有大量的SQL硬編碼到page_load和其他事件中。但他發誓他正在使用數據訪問層。定義數據訪問層
所以，我把這個問題提出來。你會如何定義一個數據訪問層？
你的同事談論的並不是大多數人認爲的DAL。 DAL應該封裝對數據庫的任何調用，無論是通過動態SQL，存儲過程還是使用類似IRepository的ORM來完成。你的網頁永遠不應該包含SQL或業務邏輯，否則它將成爲維護的噩夢。
+1這個。但是，動態SQL通常表示設計不良的訪問層。 – 2008-11-12 00:55:49
一個包含您的數據的「黑匣子」。如果是用戶關心/可以告訴有一個數據庫（除了每個考慮因素），這不是我想的
我個人將DAL定義爲應用程序和數據庫之間存在交互的地方。所以我可能會有一個與DAL交互的業務層來允許CRUD操作。
EG我可能有一個ModelClass.LoadAll（）方法可以與DAL進行交互，DAL可以獲取數據，而ModelClass可以以任何需要的方式使用該數據。
我寧願保持DAL儘可能輕，但其他人更喜歡在DAL中填充模型數據的其他方式。
對我來說，DAL就是這樣一個地方，它可以連接到我的CRUD並且只連接到數據庫 – VoltaicShock 2010-08-10 14:36:16
除了其他人所說的之外，我通常認爲它是抽象出如何存儲數據的地方。一個非常好的數據訪問層應該允許你換出Oracle，SQL Server，Access，平面文本文件，XML或任何你想要的，這樣做對其他應用程序層是透明的。換句話說，數據訪問層和其他層之間的契約應該以數據庫不可知的方式定義。
.NET的一個非常簡單的例子如下。
如果有兩個類： SomePage的（這是一個ASP.NET頁） 和 DataService的（這是一個普通的老C＃類）
如果SomePage的總是調用DataService的讀/寫數據，那麼你有一個數據訪問層。 SomePage將不包含SQL或對System.Data.SqlClient類的引用。
但SomePage可以使用DataSets或從DataService類傳遞的業務對象。
數據訪問層訪問數據，，沒有其他東西。
我願意分享這個設計數據檢索（只讀）層。
鍵架構：
DRO（ DataRetrieverObject）。DRO。該結構是基於三個步驟的結構。
使用有（重載）靜態方法的DataRetrieverFactory，每個表需要一個。使用重載來匹配不同類型的鍵。該方法將返回一個DRO。
DataRetrieverFactory將施工作業委託給第二類<TableNameAndKey>DR，它將創建實際的DRO。
在<TableNameAndKey>DR我們有一個指向DRO的指針的靜態列表，循環這個列表以查看你是否已經擁有了一個DRO和特定的鍵。
3.1。如果你找到了DRO - 檢查，如果它是確定（意爲：
3.1.1。如果DRO正確 - 然後返回DRO。
3.1.2。如果DRO不正常，則刪除該對象（及其指針），並使用數據庫中的數據創建一個新的DRO。將指針存儲在列表中。
3.2。如果指針列表中沒有命中，則我們用DB中的數據創建一個新的DRO，並將指針存儲到靜態列表中。
使用這種技術人們可以重複使用根據需要的DRO，但是該類沒有獨居，因爲我們都不允許有大量的類的實例。
有關行業標準方法，請參閱數據訪問對象。 – user924272 2016-05-14 00:40:49
訪問數據庫，並有一個數據訪問層是不一樣的。也就是說，我們需要使用某種形式的數據訪問層來訪問數據庫，所以我可以理解這種混淆。 – user924272 2016-05-14 00:45:22