MVC僅作為表示層

Question

我有一個WebAPI Web服務，它充當客戶端應用程序（WinForms和Mobile）的業務邏輯層。

現在我想創建一個僅作為表示層的MVC應用程序，我懷疑這個架構是否有意義，或者它是否打破了MVC概念。

如果它成功，MVC應用程序（作為表示層）和WebAPI服務（作為業務邏輯層）之間的正確/正確交互方式是什么？

如果有人能給我一些代碼示例，我將不勝感激。

Answer 1

如果你以這種方式使用mvc就可以了，你的控制器可以訪問webapi並將數據提供給模板。

您也可以將angularjs視為視圖/模板，並且可以將控制器調用webapi作為數據。

Answer 2

雖然我認為其他答案都是准確的，但您可能會想到其他一些問題。

首先，您的WebAPI可能是您的業務實施的地方。 實際上，您可能已經處理過：

• 與業務相關的例外
• 驗證
• 可用的操作
• 等等

除非特定功能背后的業務規則也發生變化，否則您的Api不應該發生變化。

我想在此指出的是一件事： 保持您的用戶界面完全獨立於您的API

使用帶WebApi的MVC應用程序的風險

所有代碼在一起=多個原因改變同樣的事情

通過使用MVC應用程序，您可能想要將WebApi和MVC應用程序打包在同一解決方案中。 您還可以將所有內容部署在一起。 但是這樣做，你可能會得到一大堆代碼，其中部件不會以相同的速度發展（即：用戶界面將會發生變化，但是每次需要修復UI時，Api都會發生變化。並且對API的每個更改都會影響UI。

所有代碼一起啟用快捷方式

我的意思是，如果所有內容都打包在一起，開發人員可能會試圖直接調用某個方法而不是調用應該是唯一有效的外觀的API。 任何快捷方式都可能導致代碼重復，錯誤，驗證錯誤等。再次：不要將您的MVC應用程序與您的API打包在一起。

解決方案

使用Javascript框架

其他建議很好。 AngularJS，ReactJS，EmberJS都是很好的框架。 （還有其他選擇適合您需求的那個）但同樣，它將是您的架構的一個不錯的選擇，因為您將在UI應用程序和API應用程序之間創建一個明確的分離，這是分離的問題。 您的業​​務邏輯將得到很好的保護，您將確保您的代碼僅通過HTTP調用進行調用，這是您API的唯一有效外觀。 換句話說，你確保沒有人會采取捷徑。

在自己的項目中使用.NET MVC應用程序

如果您仍想使用.NET MVC，我建議您通過HTTP調用您的API：沒有快捷方式。 我將創建一個不同的解決方案和一個單獨的MVC項目，其中使用HttpClient或類似RestSharp的方式調用API。 您想要的是避免將UI綁定到API代碼。 您希望將UI綁定到API外觀（api控制器）定義的合同而不是它們的實現。

Answer 3

我認為，如果可以在您的情況下使用其中一個JavaScript MVC框架 ，我認為更好。 我認為AngularJS，ReactJS或EmberJS將是最適合您目的的變種。 我不認為調用ASP.MVC操作，然后從那里再做一次WEB API調用，這是個好主意，imho。