我习惯于构建调用服务层（ASMX / WCF等）的C #Windows / WebForms应用程序，并使用位于WCF层之上的EF层对DB进行CRUD .
现在，我正在构建一个ASPNET MVC Web应用程序并计划使用WebAPI . WebAPI负责与EF交互 . 我担心的是，我应该直接从jQUery / javascript客户端调用webAPI，还是应该通过普通的MVC控制器来调用Web API . 如果我只是从客户端浏览WEBAPI，那么我根本不需要使用MVC吗？有哪些优点/缺点？
虽然我认为其他答案都是准确的，但您可能会想到其他一些问题 .
首先，您的WebAPI可能是您的业务实施的地方 . 实际上，您可能已经处理过：
与业务相关的例外情况
验证
可用的操作
等
除非特定功能背后的业务规则也发生变化，否则您的Api不应该发生变化 .
我想在这里指出的是一件事： Keep your user interface completely independant from your API
通过使用MVC应用程序，您可能想要将WebApi和MVC应用程序打包在同一解决方案中 . 您还可以将所有内容部署在一起 . 但是这样做，你可能会得到一大堆代码，其中部件不会以相同的速度发展（即：用户界面将会发生变化，但是每次需要修复UI时，Api都会发生变化 . 并且对API的每个更改都会影响UI .
我的意思是，如果所有内容都打包在一起，开发人员可能会试图直接调用某个方法而不是调用应该是唯一有效的外观的API . 任何快捷方式都可能导致代码重复，错误，验证错误等 . 再次：不要将您的MVC应用程序与您的API打包在一起 .
AngularJS，ReactJS，EmberJS都是很好的框架 . （还有其他的，选择适合您需求的那个）但同样，它将是您的架构的一个很好的选择，因为您将 create a clear separation between your UI app and your API app 这是分开的关注 . 您的业务逻辑将得到很好的保护（WebApi），您将确保您的代码仅通过HTTP调用进行调用，这是API的唯一有效外观 . 换句话说，你确保没有人会采取捷径 .
如果您仍想使用.NET MVC，我建议您通过HTTP调用您的API：没有快捷方式 . 我将创建一个不同的解决方案，并使用一个单独的MVC项目，使用HttpClient或类似RestSharp的方式调用API . 您想要的是避免将UI绑定到API代码 . 您希望将UI绑定到API外观（api控制器）定义的 Contract 而不是它们的实现 .
这里有一点行话混乱，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以加载特定的异步内容（例如，填充下拉列表， ...）
我相信你应该从你的MVC应用程序中调用它，因为你会有更多
控制安全性并调用和修改发送到WebAPI和从WebAPI接收的数据 .
例如，您可以将当前登录用户的ID发送到Web API，但您无法执行此操作
来自JQuery .
此示例视频向您展示了针对您的方案的简单步骤 .
https://www.youtube.com/watch?v=bvYy1ZcUZWU
3 回答
虽然我认为其他答案都是准确的，但您可能会想到其他一些问题 .
首先，您的WebAPI可能是您的业务实施的地方 . 实际上，您可能已经处理过：
与业务相关的例外情况
验证
可用的操作
等
除非特定功能背后的业务规则也发生变化，否则您的Api不应该发生变化 .
我想在这里指出的是一件事： Keep your user interface completely independant from your API
使用带WebApi的MVC应用程序的风险
所有代码在一起=多个原因改变同样的事情
通过使用MVC应用程序，您可能想要将WebApi和MVC应用程序打包在同一解决方案中 . 您还可以将所有内容部署在一起 . 但是这样做，你可能会得到一大堆代码，其中部件不会以相同的速度发展（即：用户界面将会发生变化，但是每次需要修复UI时，Api都会发生变化 . 并且对API的每个更改都会影响UI .
所有代码一起启用快捷方式
我的意思是，如果所有内容都打包在一起，开发人员可能会试图直接调用某个方法而不是调用应该是唯一有效的外观的API . 任何快捷方式都可能导致代码重复，错误，验证错误等 . 再次：不要将您的MVC应用程序与您的API打包在一起 .
解决方案
使用Javascript框架
AngularJS，ReactJS，EmberJS都是很好的框架 . （还有其他的，选择适合您需求的那个）但同样，它将是您的架构的一个很好的选择，因为您将 create a clear separation between your UI app and your API app 这是分开的关注 . 您的业务逻辑将得到很好的保护（WebApi），您将确保您的代码仅通过HTTP调用进行调用，这是API的唯一有效外观 . 换句话说，你确保没有人会采取捷径 .
在自己的项目中使用.NET MVC应用程序
如果您仍想使用.NET MVC，我建议您通过HTTP调用您的API：没有快捷方式 . 我将创建一个不同的解决方案，并使用一个单独的MVC项目，使用HttpClient或类似RestSharp的方式调用API . 您想要的是避免将UI绑定到API代码 . 您希望将UI绑定到API外观（api控制器）定义的 Contract 而不是它们的实现 .
这里有一点行话混乱，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以加载特定的异步内容（例如，填充下拉列表， ...）
我相信你应该从你的MVC应用程序中调用它，因为你会有更多
控制安全性并调用和修改发送到WebAPI和从WebAPI接收的数据 .
例如，您可以将当前登录用户的ID发送到Web API，但您无法执行此操作
来自JQuery .
此示例视频向您展示了针对您的方案的简单步骤 .
https://www.youtube.com/watch?v=bvYy1ZcUZWU