在普通的ASP.Net MVC應用程序中使用Web API的好處

在基於正常CRUD的ASP.NET MVC應用程序中使用Web API有什麼好處嗎？我知道使用Web API的確給我們帶來了RESTful服務層的好處，但我並不贊成替換整個服務層（以及底層的業務層和數據訪問層），只使用服務來訪問數據庫。相反，我覺得我們應該將少數功能作爲服務公開，並在需要時提供服務，以防客戶端想要支持其他應用程序，如SPA或移動版本的應用程序。在普通的ASP.Net MVC應用程序中使用Web API的好處

問題是，在我的情況下，大多數工作是否將複雜的html視圖主要返回給一個應用程序，而內部操作主要是CRUD，也許某些業務邏輯對於完成服務有意義層？是否有任何性能問題，因爲必須創建代理。這種架構在擴展方面有什麼好處？太多問題。只是困惑。我沒有看到需要，但也許我錯過了什麼？

擁有SOA的想法看起來不錯，但是擔心如果存在性能下降的問題。

來源

2013-10-17 Arathy T N

我相信這是一個更好的選擇，在網站和web API之間共享業務邏輯庫比它是有服務器端網站代碼調用Web API。

HTTP協議針對低延遲和獨立演進的組件進行了優化。如果同一個團隊同時控制網站和Web API，並且它們同時部署，並且它們都住在同一個數據中心，那麼使用HTTP進行對話就沒有多大價值。

如果您嘗試使用Web API向您的網站提供數據，您將遇到的另一個問題是您可能會構建一個可在您的數據中心正常工作的健談Web API，但是當遠程客戶端嘗試並使用它時可能會有性能問題。

如果您希望第三方使用的Web APIs高效高效，那麼應該構建它們來公開用例，而不是您的網站需要訪問的域實體。

來源

2013-10-18 12:19:09

因此，您認爲將業務邏輯層用作網站中的組件，然後添加web api層以暴露第三方用例或甚至可以使用SPA移動版本我們的應用程序？在以下鏈接中的策略2是我猜你在暗示什麼 - http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and- webapi.aspx –

@ user1473638是的。一種方法是將業務層發佈爲內部可用的Nuget包。這可以使管理業務邏輯的不同版本變得更容易。 –

的WebAPI將是一個好主意，你在兩種情況下：

其他應用程序可能需要訪問相同的數據，你只需要編寫一次業務邏輯/數據訪問邏輯。
你想編寫瀏覽器端JavaScript，將AJAX調用回到應用程序的服務器端來檢索數據。

對於＃2，您也可以使用常規的MVC和JsonResponse處理程序。在我的應用程序中，我使用兩者如果我只是返回數據，並且我想直接序列化我的模型對象，那麼我將設置一個WebAPI控制器。但是如果我需要通過Razor模板運行模型，我的控制器上有一個擴展方法，它允許我將視圖渲染成一個字符串，然後將其作爲一個屬性返回給JSON對象，併爲其他屬性設置元數據我需要返回像成功代碼，錯誤消息，序列化的異常對象等

來源

2013-10-17 19:29:14 DougWebb

是的，爲1.我只是想知道我是否可以編寫一個服務層（更像是一個API），它會調用相同的業務邏輯層（類庫）。那可能嗎？我是否需要重寫業務層？事後我決定某些業務功能需要作爲服務提供？在我看來，web api服務層可以位於業務層的頂層，而不需要編寫整個業務層和DAL層。這甚至可行嗎？ –

不，應該不需要使用不同的業務層，或稍後爲了添加WebAPI服務層而對其進行修改，只要您將UI邏輯與業務邏輯完全分離即可。例如，我經常使用業務層模型作爲傳遞給我的視圖的模型，但我也創建了UI特定的模型類，以便將UI特定的信息傳遞給我的視圖。這些模型進入MVC項目的/ Models文件夾，而其他模型通常位於業務層的單獨庫項目中。這有助於保持圖層的獨立性和業務模型在服務中的可用性。 – DougWebb

在普通的ASP.Net MVC應用程序中使用Web API的好處

回答

相關問題