我的服務設計不好嗎？

Question

我正在開發遵循MSDN的service archetype的WCF服務。也就是說，我遵循該文章中的大部分指導原則，並將我的數據和服務合約放在服務層的單獨程序集中。問題在於，該服務主要基於底層數據庫與其客戶端應用程序之間的事務處理，因此我在數據庫中每個實體幾乎有一個類（數據合同）。由於服務層不應直接訪問DAL，因此我在業務層中有一組接收傳遞給服務的參數的方法，從服務層實例化相應的實體並與DAL（企業庫的DAAB）通信以進行CRUD操作。然而，我覺得這些CRUD操作屬於服務層中的每個類，但將它們放置在那裏會使服務層直接調用DAL ...我的問題是：

1）有一個數據每個數據庫實體的合同是不好的做法

2）CRUD操作是否應直接放置在服務層上（從而導致服務層直接依賴於DAL程序集）？ - 或 -

3）我應該爲業務層中的每個合同創建一個包裝類，並將CRUD操作放在那裏，使用（可能）接口方法在層之間進行通信？

Answer 1

嚴格要求每個數據庫實體的一個數據合同是一個人爲的限制。在具有數據庫實體的簡單應用程序中，所有交互作用都是對這些實體的單獨CRUD操作，它可能會保持不變。但在一個更復雜的應用程序中，通常需要跨多個數據庫實體進行連接，甚至在一次批處理調用（批次或存儲過程）中更新許多實體。

我可能不會直接從服務層訪問DAL。擁有一個業務層允許您完全改變持久化數據的方式，同時允許您直接對業務層進行單元測試，而無需啓動服務。

接口可以幫助解耦，但它不是一個嚴格的要求。業務層可以使用契約定義其數據需求，並且可以將數據源對象（dal）作爲實現接口的委託來提供給業務層 - 它將這些層分離。這允許您編寫業務層並讓它定義需要的數據，然後讓DAL實現。這與創建CRUD對象和以堆疊的另一種方式設計層相反。關注業務問題，定義需要哪些數據來滿足業務需求，然後編寫能夠儘快實現這些需求的DAL。設計下來的堆棧。總而言之，我將重點關注如何構建一個向客戶端公開邏輯操作的服務，其中業務層實施規則和數據層，以滿足業務層的要求。在設計這些層時，着重於性能，儘量減少往返時間，並縮短連接和事務處理時間。