ASP.NET MVC消費WCF

Question

我的ASP.NET MVC 2控制器當前通過傳遞由Castle Windsor實例化的存儲庫實例在其構造函數中實例化服務對象。我有單元測試，在將存儲庫的Moq實例傳遞給控制器​​的構造函數後調用控制器動作。

我想允許第三方UI通過WCF訪問這些服務對象。

我發現把我現有的服務層轉換成Web服務，甚至在UI和現有服務層之間添加一個新的Web服務層將會破壞我的單元測試，除非我找到彌合這種差距的方法。

我試圖找出一個解決方案，其中我的UI是根據服務層的接口進行編碼的（現在已經是這樣），我可以使用DI在運行時傳遞Web服務實現，並在現有實現期間傳遞單元測試。 Web服務實現只需調用現有的實現。

問題：

1. 是這樣的做法可取/可能嗎？
2. 在教程或開源項目中是否有這樣的例子？

編輯：

我相信我有一個可行的解決方案現在多虧了下面的建議。我創建了一個WCF服務應用程序，它使用我的域模型中的現有服務接口。 WCF實現是一個類，構造函數從Ninject的WCF extension獲取存儲庫實例，並從域模型創建服務實例。 WCF中的每個方法/函數都只是從現有的服務層調用相同的方法/函數。

有一些注意事項。例如，當我在控制器中創建服務時（實際上，我使用Ninject創建WCF服務的實例並將其提供給控制器的構造函數），我無法再傳遞對ASP.NET MVC ModelState的引用。原因在於WCF是一個消息傳遞平臺 - 每次調用都必須明確傳達更改（即，我的驗證錯誤現在作爲各個函數/方法的參考參數傳回）。

我還必須添加一些序列化/ servicemodel引用到我以前的POCO Core項目。

另外，我從Castle轉換到Ninject，因爲Castle's WCF solution的成熟度很低，我當時並不習慣使用它。

Answer 1

您能否更詳細地解釋爲什麼您的測試會中斷？

我一直在做這種類型的開發。作爲類的服務=>作爲WCF服務的服務。

您的測試不應該中斷。 WCF服務幾乎是100％的合同，底層的業務代碼和邏輯不應該改變。

Answer 2

查看Web Services Software Factory由圖案創建&實踐團隊。將服務構建爲合同項目（數據，消息，服務）和「業務代碼」是一種很好的方法。一旦你對如何構建代碼有了更好的理解，你可以將它們的風格重構爲適合你的東西。他們的例子傾向於將所有東西都分成許多VS項目，這對大多數商店來說可能有點矯枉過正。例如，我沒有看到許多商店跨項目共享數據合同。是的，在一個完美的世界裏，你應該可以在不同的項目中分享很多操作系統類型（比如地址），但是我不會經常看到它的完成。所以，我傾向於把我所有的合同放在一個VS項目中。

Answer 3

如果你的服務已經被定義爲接口，那麼你已經有了一個良好的開端。

將服務作爲構造函數依賴關係傳遞給控制器​​，而不是存儲庫。讓您的DI容器A）向服務提供存儲庫，並且B）向控制器提供服務。

如果您希望將服務層作爲wcf服務站起來以供其他應用程序訪問，則需要使用wcf服務工廠將實際的服務實現從您的DI容器中提取出來。 Here's an example with windsor，它應該很容易適應你使用的任何容器。

此時，您可以將您的網站修改爲：A）繼續直接調用服務;或者B）讓他們使用服務客戶端回調Web服務。這兩種方法都有優點和缺點。