「數據服務層」和「數據訪問層」有什麼區別？

Question

我記得讀過一個將低級調用抽象爲數據不可知的框架（例如ExecuteCommand方法等），另一個通常包含業務特定的方法（例如UpdateCustomer）。

這是正確的嗎？哪個是哪個？

Answer 1

對我而言，這是一個關於如何處理項目設計的個人設計決策。有時數據訪問和數據服務是一樣的。對於.NET和LINQ來說就是這樣。

對我來說，數據服務層實際上是對數據庫的調用。數據訪問層接收對象並創建它們或修改它們以供數據服務層調用數據庫。

在我的設計中，業務邏輯層根據業務規則處理對象，然後將它們傳遞給數據訪問層，數據訪問層將格式化爲從數據庫進入數據庫或對象，數據服務層處理實際的數據庫調用。

Answer 2

我認爲一般來說這兩個術語是可以互換的，但根據開發環境的上下文可能有更具體的含義。

數據訪問層位於數據和應用程序之間的邊界。 「數據」僅僅是應用程序使用的各種數據源。這可能意味着必須在每個應用程序中進行實質性編碼，才能將數據從多個來源中提取出來。創建所需數據視圖的代碼在某些應用程序中將是冗餘的。隨着數據源數量的增加和變得越來越複雜，有必要將數據訪問的各種任務隔離到數據訪問，轉換和集成的詳細地址。通過精心設計的數據服務，商業服務將能夠與更高抽象級別的數據進行交互。處理數據訪問，集成，語義解析，轉換和重構以解決應用程序所需的數據視圖和結構的數據邏輯最好封裝在數據服務層中。甚至進一步將數據服務層分解爲其組成部分（即數據訪問，轉換和集成）是可能的。在這種情況下，您可能只有一個「數據訪問層」，它只涉及檢索數據;「數據服務層」通過數據訪問層檢索其數據，並將檢索到的數據組合並轉換爲各種對象業務服務層。

Answer 3

的數據服務層概念WebSphere Commerce文檔中所做的是直接的：

數據服務層（DSL）提供了一種用於數據訪問的抽象層獨立於物理模式的。 數據服務層的目的是提供一致的接口（稱爲數據服務facade）用於訪問數據，獨立於對象關係映射框架的

當前在互聯網的DSL概念是主要關聯的與SOAs（面向服務的體系結構），但不僅如此。在N層應用程序的示例中提到了Here。

Answer 4

這裏是從戰壕深處的另一個角度！數據訪問層是一個軟件抽象層，它隱藏了實際獲取數據的複雜性/實現。應用程序要求數據訪問層（請參閱DAO設計模式）「讓我這個」或「更新」等（間接）。數據訪問層負責執行特定於實現的操作，例如讀取/更新各種數據源，例如Oracle，MySQL，Cassandra，RabbitMQ，Redis，簡單文件系統，緩存或者委託給另一個數據服務層。

如果所有這些工作發生在單臺機器和同一個應用程序中，術語數據服務層相當於服務外觀（間接）。它負責提供服務並將應用程序調用委託給正確的數據訪問層。

有點令人困惑的是，在分佈式計算世界或面向服務的體系結構中，數據服務層實際上可以是一個作爲獨立應用程序的Web服務。在這種情況下，數據服務層將接收到的上游應用程序數據請求委託給正確的數據訪問層。在這種情況下，Web服務是指向應用程序的數據訪問 - 應用程序只需要知道調用什麼服務來獲取數據，因此，在分佈式計算環境中經驗法則，這種方法將降低應用程序的複雜性（並且總是會有例外情況）

所以要清楚的是，應用程序使用DSL和DAL。應用程序中的DSL應與同一應用程序中的DAL進行通話。 DAL可以選擇使用單個數據源，或委託給其他Web服務。 Web服務DSL可以將工作委派給DAL以處理該請求。事實上，單個Web服務請求可能會使用多個數據源來響應數據。

儘管如此，從務實的角度來看，只有當系統變得越來越複雜時，才應該更多地關注架構模式。做正確的事情是一個很好的做法，但沒有必要在工作中鍍金。還記得YAGNI嗎？那麼，它沒有產生共鳴來到它需要的時間！總結：David Wheeler着名的格言是：「計算機科學中的所有問題都可以通過另一層級的間接方式來解決」; [1]這通常被故意錯誤地用「抽象層」代替「層次」間接「。凱夫琳亨尼對此的必然結論是「......除了間接層數過多的問題。」