我正在构建一个 ASP.NET MVC 应用程序,它的客户端脚本很多,它将使用 JSON 和 jQuery 来操作 DOM。
我的理解是 Web API 控制器和 MVC 控制器都可以返回 JSON。
根据我的场景,我应该使用 Web API 控制器还是 MVC 控制器?
WebAPI 是用来制作 API 的。如果您希望有人能够使用您的 XML、 JSON 等 API。你可以做一个网络应用程序接口。
在您的情况下,您只需要使用 JSON 与客户机交谈。
即使你的网站主要是客户端脚本驱动的,你还是会使用 ASP.NET MVC 控制器,对吗?由于您可能已经根据实体在逻辑上划分了控制器,因此在其中添加那些 json 服务方法是有意义的,而不是专门为 Web API 创建另一个类。
所以对于你的特殊情况(如果我理解正确) ,我会坚持控制器。
答案可以归结为关注点分离、加快服务的创建,以及依赖惯例而非配置。
控制器的主要职责是作为视图和模型之间的协调器,而 API 的主要职责是处理数据。对于 API 的约定,执行 CRUD 操作非常容易。下面是 CRUD 操作和 HTTP 操作之间的映射
因此,使用 API 时,您不必创建单独的操作,并将它们与 HTTP 操作相关联。
Web API 控制器可以在任何 ASP.NET 应用程序中创建和托管,而不仅仅是 MVC 应用程序。因此,创建 Web API 的一个显而易见的原因是,如果您没有 MVC 前端(例如,由您的公司/组织托管的经典的 RESTful Web 服务)
MVC 控制器通常依赖于 MVC 框架,如果你查看默认模板以及社区和同行完成的大部分工作,你会注意到几乎所有的 MVC 控制器都是在使用 View 的情况下实现的。
就个人而言,当我打算使用 View ()来响应时,我会使用 MVC 控制器,并且对于不依赖于特定视图的任何东西,我都会使用 Web API。
当然,这里有一些警告,但是一般来说,如果你不需要 MVC 的模型绑定行为,你的服务是以数据为中心的,操作是以数据为中心的(例如 CRUD 操作) ,那么你可能需要一个“ Web API 控制器”而不是“模型-视图控制器”。相反,如果你的操作是以视图为中心的(例如向用户提供一个用户管理页面) ,或者你需要 MVC 的模型绑定来生成“ ajax 部分”(这种可能性很小) ,那么你就需要一个 MVC 控制器来代替。
就个人而言,我使用 Web API 控制器来驱动基于 JSON 的 RESTful 客户机,我使用 MVC 控制器来处理基本的浏览器路由和 SPA 的传递。
我对 ApiController 的唯一担心是它是基于站点的,而不是基于区域的。 一个站点只能有一个 apicontroler 子文件夹,用于命名控制器方法。 有些情况下,您可能希望在不同的区域中复制控制器名称:
Domain.com/api/area1/controller1/
Domain.com/api/area2/controller1/
我记得有一些自定义代码设置能够这样做,但它不工作的默认情况下。
我同意肖恩 · 威尔逊的回答,但是不知道为什么,因为我只是有点困惑,并且仍然试图理解以下(可能是错误的)预感-
你看,我只是不知道为什么我在这里是不正确的,并且感到困惑,因为 Shaun 的答案的最后一行说: “我使用 MVC 控制器处理基本的浏览器路由和 SPA 的传递。” 也许我不完全知道什么是静态客户端,当我假设它可能是 JavaScript 方法,接收 JSON 形式的响应。这是在 Stackoverflow 最接近的帖子,作为对我的问题的一个远程回答,所以我回答这个帖子,而不是可能重复的问题。
在这个场景中,我建议使用 WebApi,因为它非常适合基于 Javascript 请求传输数据。我通常会开发我的 WebApi 控制器,这样它们就会返回一个 JSON 友好的对象,然后我的 Javascript 就可以很容易地解析这个对象。
在 MVC 控制器上,只有在生成一些 HTML 并用 Javascript 调用替换页面片段时,才会实时地使用动作。
例如:
您有一个 JQueryUI Datepicker,它在选择后生成一个单选按钮列表,这些按钮表示选定日期的事件。
在这个场景中,您可以使用 WebApi 返回一些 JSON,然后使用 Javascript 生成必要的 HTML,但是通常使用 Javascript 创建大量 HTML 是不好的做法。最好是用 C # 构建 HTML,然后通过部分视图返回它,因为这样就不太可能在 Javascript 解析中遇到错误。更不用说它使 HTML 更容易编写了。