ASP.NET Web API體系結構建議/反饋

目前我正面臨構建Web服務的需求，該服務將使Java客戶端通過httprequest獲取並觸發對我們數據的操作。我們是一個.Net商店，它的最新解決方案是Microsoft的MVC4 Web API。我習慣了你的標準分層架構，我從API中抽取了數據，但這將是我的第一個提供數據的Web服務。ASP.NET Web API體系結構建議/反饋

從我的研究，我所看到的建議如下：

邏輯和數據訪問分離成一個單獨的項目類型的類庫。
使用您的控件訪問數據並執行邏輯。
使用您的模型來訪問數據和執行邏輯。

我正在尋找有經驗的MVC4 Web API的人員，他們可以通過這種方式瞭解構建Web服務的良好實踐。

在此先感謝。

來源

2012-11-07 vikingben

歡迎來到stackoverflow！我認爲這個問題有點含糊。你能解釋一下你究竟想做什麼嗎？例如：「我的Web服務的設計應該是什麼？這就是我的想法」？也許......這個問題似乎太開放了。 – Parris

感謝您的迴應和歡迎。我擔心我的問題的模糊性與我對MVC 4產品的知識相符。我在想兩個選擇。第一種選擇是將我的邏輯和數據訪問分離爲單獨的類庫項目，以便重用代碼和更好的組織。或者，另一種選擇是使用MVC shell，並使用該模型來實現業務邏輯和數據訪問，因爲這個項目變得越來越大，我覺得可能會變得非常擁擠。 – vikingben

ASP.NET Web API！= ASP.NET MVC http://www.tugberkugurlu.com/archive/newsflash-asp-net-web-api-does-not-sit-on-top-of-asp-net- mvc-in-fact-it-do-not-sit-of-top-of-anything只是FYI :) – tugberk

首先，請將您的ASP.NET Web API邏輯放入一個單獨的項目中。這將使您比託管層更靈活（因爲ASP.NET Web API託管不可知），它只是使整個項目變得清晰。假設你的項目名稱是MyProject。您可以將該API項目命名爲MyProject.API，並且您可以將Microsoft.AspNet.WebApi.Core NuGet軟件包安裝到此項目中。

我還建議你分開你的域圖層（POCO實體，存儲庫，你的服務層件等）。我們稱之爲MyProject.Domain。然後，您可以參考MyProject.API項目的MyProject.Domain項目。

我不會推薦你將所有的POCO實體轉儲到你的API中。所以，我肯定會使用數據傳輸對象（Dto）。您可以使用像autoMapper這樣的第三方工具將您的實體類映射到您的Dtos。但是，請將您的Dtos，請求命令，請求模型放入單獨的項目中。您可以參考MyProject.API項目MyProject.API.Model項目。爲什麼我們爲此創建一個單獨的項目？因爲，稍後如果您決定爲您的HTTP API構建.NET客戶端封裝器，則可以輕鬆地引用此項目以將其用於.NET客戶端。我們稱這個項目爲MyProject.API.Model。

最後，我們需要我們的API的託管層。如果您希望在ASP.NET下託管此項目，則可以通過空Web應用程序模板創建一個新項目，並將其稱爲此項目MyProject.API.WebHost。然後，您可以將Microsoft.AspNet.WebApi包安裝到此項目中。從這個項目中，您可以參考MyProject.API,MyProject.API.Model和MyProject.Domain項目。該項目是您應該部署到您的服務器的項目。

如果您想爲HTTP API創建.NET包裝器，則可以創建另一個名爲MyProject.API.Client的項目並將Microsoft.AspNet.WebApi.Client包安裝到此包中。你也可以參考MyProject.API.Model這個項目，這樣你就可以反序列化並從強類型對象序列化。

這裏是解決方案瀏覽器，因爲我一直在與項目工作的截圖：

enter image description here

希望這給你一點想法的。

來源

2012-11-08 09:02:25 tugberk

你的反饋。我很欣賞快速反應。 – vikingben

： - \這真的開始聽起來像https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition –

@DanEsparza讓我知道，如果這些層中的任何一個對你沒有意義，我會告訴你爲什麼它在那裏。 – tugberk

ASP.NET Web API體系結構建議/反饋

回答

相關問題