我习惯于构建调用服务层（ASMX / WCF等）的C＃Windows / WebForms应用程序，并使用位于WCF层之上的EF层对DB进行CRUD。
现在，我正在构建一个ASPNET MVC Web应用程序并计划使用WebAPI。 WebAPI负责与EF交互。我担心的是，我应该直接从jQUery / javascript客户端调用webAPI，还是应该通过普通的MVC控制器来调用Web API。如果我只是从客户端浏览WEBAPI，那么我根本不需要使用MVC吗？ 有什么利弊？
答案 0 :(得分：3)
这里有一点行话混乱，MVC本身不是UI或WebApi。将MVC视为组织/设计代码/解决方案的方法论。
您可以使用jquery直接调用webapi。但是jquery将在哪里托管，你需要一个页面，谁将为页面提供服务，它将是服务器代码。你会做更多繁重的服务页面和那些调用webapi的页面。
如果你的android / ios上的应用程序试图与后端进行交互，你会选择webapi的路径，当你想加载内容异步时，你也会有网页调用webapi。
所有这些都说，这就是我组织代码的方式： 1.利用MVC为页面和web api提供服务。 2.使web api和网页控制器调用公共底层EF / infra代码 3.浏览器用户使用页面，应用程序使用web apis 4.浏览器页面还调用web api来加载特定的异步内容（例如，填充下拉列表，......）
答案 1 :(得分：2)
虽然我认为其他答案都是准确的，但您可能会想到其他一些问题。
首先，您的WebAPI可能是您的业务实施的地方。实际上，您可能已经处理过：
除非某个功能背后的业务规则发生变化，否则您的Api不应该发生变化。
我想在此指出的是一件事： 让您的用户界面完全独立于您的API
通过使用MVC应用程序，您可能想要将WebApi和MVC应用程序打包在同一解决方案中。您还可以将所有内容部署在一起。但是这样做，你可能会得到一大堆代码，其中部件不会以相同的速度发展（即：用户界面将会发生变化，但是每次需要修复UI时，Api都会发生变化。并且对API的每个更改都会影响UI。否。）
我的意思是，如果所有内容都打包在一起，开发人员可能会试图直接调用某个方法而不是调用应该是唯一有效外观的API。采取的任何快捷方式都可能导致代码重复，错误，验证错误等。 再说一遍：不要将您的MVC应用程序与您的API打包在一起。
AngularJS，ReactJS，EmberJS是很好的框架。 （还有其他选择适合您需求的那个）但同样，它将是您的架构的一个不错的选择，因为您将在您的UI应用程序和您的API应用程序之间创建明确的分离关注。您的业务逻辑将得到很好的保护（WebApi），您将确保您的代码仅通过HTTP调用进行调用，这是API的唯一有效外观。换句话说，你确保没有人会采取捷径。
如果您仍想使用.NET MVC，我建议您通过HTTP调用您的API：没有快捷方式。我将创建一个不同的解决方案，并使用一个单独的MVC项目，使用HttpClient或类似RestSharp的方式调用API。您想要的是避免将UI绑定到API代码。您希望将UI绑定到API外观（api控制器）定义的合同而不是它们的实现。
答案 2 :(得分：0)
我相信您应该从MVC应用程序中调用它，因为您将有更多
控制安全性并调用和修改发送到WebAPI和从WebAPI接收的数据。
例如，您可以将当前登录用户的ID发送到Web API，但不能这样做
来自JQuery的。
此示例视频向您展示了针对您的方案的简单步骤。