如果以这种方式使用mvc，那么控制器就可以访问webapi并将数据提供给模板。

您也可以将angularjs视为视图/模板，那里的控制器可以调用数据的webapi。

虽然我认为其他答案是准确的，但您可能会想到其他一些问题。

首先，您的WebAPI可能是实现业务的地方。事实上，你可能已经处理：

• 业务相关异常
• 验证
• 可用操作
• 等等

你的Api是不应该改变的，除非某个功能背后的业务规则也改变了。

我想指出的是：保持您的用户界面完全独立于您的API

将MVC应用程序与WebApi一起使用的风险

所有代码加在一起=改变同一事物的多种原因

通过使用MVC应用程序，您可能会想将WebApi和MVC应用程序打包在同一个解决方案中。您还可以将所有的东西部署在一起。但这样做，你可能会得到一大堆代码，其中的部分并没有以相同的速度发展（即：用户界面会经常变化，但Api会在每次需要UI修复时发生变化。不。Api的每次变化都会影响UI。不。）

所有代码一起启用快捷方式

我的意思是，如果所有东西都打包在一起，开发人员可能会直接调用某些方法，而不是调用应该是唯一有效门面的API。采取任何快捷方式都可能导致代码重复、错误、验证错误等。再次强调：不要将你的MVC应用程序与API打包。

解决方案

使用Javascript框架

其他建议都不错。AngularJS、ReactJS、EmberJS都是不错的框架。（还有其他，请选择适合您需求的）但是，对于您的体系结构来说，这将是一个很好的选择，因为您将在UI应用程序和API应用程序之间创建一个明显的分离，这是分离的问题。您的业务逻辑将得到很好的保护，并且您将确保您的代码仅通过HTTP调用进行调用，这是API的唯一有效门面。换句话说，你要确保没有人会走捷径。

在自己的项目中使用.NET MVC应用程序

如果你仍然想使用.NETMVC，我建议你通过HTTP:no快捷键调用API。我将创建一个不同的解决方案，并使用一个单独的MVC项目，其中将使用HttpClient或类似RestSharp的东西来调用API。这里您想要的是避免将UI绑定到API代码。您希望将UI绑定到由API门面（API控制器）定义的契约，而不是它们的实现。

当然，如果在您的情况下可能的话，我认为最好使用JavaScriptMVC框架之一。我认为AngularJS、ReactJS或EmberJS将是最酷的变体。我不认为调用ASP.MVC操作，然后从那里再调用WEB API是个好主意，imho。