帶有依賴注入的WCF數據契約設計

Question

所以我有一個分層的應用程序，我在其上添加了一個WCF服務接口。該服務僅僅是一個外觀，其業務邏輯已經存在於商業邏輯層（BLL）中的Business Objects（BO）中，該BLL是一個類庫。在BLL中，我們使用構造器注入來向BO中注入依賴關係。這一切都與良好的單元測試等工作。對問題...

通常，我只需創建一組請求/響應對象作爲DataContracts爲每個服務方法與適當的操作屬性。如果操作需要我們的一個「實體」傳遞給方法或從方法傳遞，我只需定義一個該類型的屬性，一切都會好的（我們所有的BO都是可序列化的）。然而，當這些「實體」中的一個被傳入服務方法時，WCF將對象反序列化，而不會調用我們定義的構造函數，因此，依賴關係不會解析。

我們使用服務方法的情況，稱爲CreateSomething。我通常喜歡用簽名將此定義爲服務操作：

CreateSomethingResponse CreateSomething(CreateSomethingRequest request); 

CreateSomethingRequest將是一個DataContract，已位居其屬性類型的屬性東西那代表的「實體」被傳遞到服務。 在這種情況下，這是一個業務對象，當實例化時，這個業務對象預期會從DI容器接收實例 - 正如我上面所說的，當WCF反序列化服務器上​​的對象時，不會發生這種情況。

選項＃2是從DataContract刪除東西屬性，並以我DataContract明確定義每個屬性，然後我的服務方法內，創建東西類的新實例，讓容器注入依賴關係，然後將來自DataContract對象的屬性值映射到BO中。我當然可以這樣做，但是我擔心現在有兩個地方可以進行更改，例如，如果我想將屬性添加到Something類型。而且，由於很多屬性，代碼重複很多。

有沒有人跨過這座橋，如果有的話，你能分享一下你的想法，以及你在自己的應用程序中是如何處理這種情況的？謝謝！！！

Answer 1

謝謝，拉迪斯拉夫，你的回答，因爲你確認了什麼已經在我腦海中。

我最終做的是改變我的方法。我意識到，我本身對商業對象的使用是過度和不必要的。或者，也許只是誤導了。在評估我的要求時，我意識到我可以「簡化」我的方法並使一切正常。通過在我的應用程序中獲取每個邏輯層並查看層間需要傳遞的數據，我發現了一種可行的設計。

首先，對於我的業務邏輯層而不是業務對象，我實現了一個工作單元對象：SomethingManager。 SomethingManager綁定到我的根東西實體，以便任何行動我想執行或與東西通過SomethingManager完成。這包括諸如GetById，GetAll，Save和Delete之類的方法。

的SomethingManager類接受在其構造兩個對象：一個IValidator <東西>和ISomethingRepository。這些將由IoC容器注入。前者允許我使用我們選擇的任何框架（最初是驗證應用程序塊）執行所有必要的驗證，後者讓我堅持不懈，並且抽象了今天使用Linq-to-SQL並稍後更容易升級到EF4。

對於我的服務層，我將IoC容器（本例中爲Unity）連接到WCF中，以便服務實例由容器創建。這允許我將ISomethingManager的實例注入到我的服務中。使用該接口，我可以打破依賴關係並輕鬆地對服務類進行單元測試。另外，因爲容器正在注入實例，所以它正在構建它並自動解決它的依賴關係。

然後我創建了DataContracts來表示數據在通過服務通過線路傳輸時應該如何顯示。每個Request/Response對象都包含這些DataContracts作爲DataMembers，而不是直接引用我的實體類（或BO）。這是服務方法來映射來自或去往業務邏輯層（通過ISomethingManager）的數據 - 使用AutoMapper使這個清潔和高效。

回到數據層，我簡單地通過定義一個實現BLL所需接口的部分類來擴展生成的實體類。例如，L2S實體具有部分定義的實現ISomething。而ISomething是什麼SomethingManager（和ISomethingManager接口）和以使它很容易地查詢數據庫，並通過L2S實體環比上漲爲服務層消耗和傳承（不ISomethingRepository工作服務層對L2S實現具有任何知識或依賴性）。

我很欣賞任何人對此方法的評論，問題，批評或建議。

Answer 2

有關於你的問題兩個答案：

第一：不要把你的實體和使用數據傳輸對象來代替。您的實體是具有邏輯和數據的業務對象。業務對象的邏輯很可能用於控制數據。因此，讓業務對象在業務層中控制其數據並僅交換虛擬箱。

第二：如果您不想遵循第一種方法，請檢查您的IoC容器的文檔。通常有兩種解決依賴性的方法。例如統一提供：

• Resolve - 建立新的實例，並注入所有的依賴關係（必需的構造函數注入）
• BuildUp - 採用現有的實例，並解決了所有財產的依賴。這應該是你的選擇。