ChatGPT解决这个技术问题 Extra ChatGPT

在 ASP.NET 中使用 WebAPI 或 MVC 返回 JSON

我正在构建一个客户端脚本繁重的 ASP.NET MVC 应用程序,它将使用 JSON 和 jQuery 来操作 DOM。

我的理解是 Web API 控制器和 MVC 控制器都可以返回 JSON。

鉴于我的场景,我应该使用 Web API 控制器还是 MVC 控制器?

需要注意的是,这个问题是特定于特定上下文的:作者想知道如果只返回 json 应该使用什么控制器。 REST API 允许根据内容协商使用不同的媒体格式(例如:接受 xml、接受 json)。在这种情况下,WebAPI 控制器是您的最佳选择

S
Shaun Wilson

Web API 控制器可以在任何 ASP.NET 应用程序中创建和托管,而不仅仅是 MVC 应用程序。因此,创建 Web API 的一个明显原因是如果您没有 MVC 前端(例如,由您的公司/组织托管的经典 RESTful Web 服务。)

MVC 控制器通常依赖于 MVC 框架,如果您查看默认模板以及社区和您的同行所做的大部分工作,您会注意到几乎所有 MVC 控制器都是在考虑视图的情况下实现的。

就个人而言,当我打算使用 View() 进行响应时,我会使用 MVC 控制器,并且我将对不依赖于特定视图的任何事情使用 Web API。

当然,有一些警告,但一般来说,如果您不需要 MVC 的模型绑定行为,您的服务是以数据为中心的,并且操作是以数据为中心的(例如 CRUD 操作),那么您可能需要一个“Web API 控制器” ' 而不是“模型视图控制器”。相反,如果您的操作是以视图为中心的(例如,向用户提供用户管理页面),或者您需要 MVC 的模型绑定来生成“ajax 部分”(不太可能),那么您将需要一个 MVC 控制器。

就我个人而言,我使用 Web API 控制器来驱动基于 JSON 的 RESTful 客户端,我使用 MVC 控制器来处理基本的浏览器路由和 SPA 的交付。


M
Muhammad Hasan Khan

WebAPI 用于制作 API。如果您希望某人能够以 XML、JSON 等格式使用您的 API。您可以制作一个 Web API。

在您的情况下,您只需要用 JSON 与客户交谈。

即使您的网站主要是客户端脚本驱动的,您仍然会使用 ASP.NET MVC 控制器,对吗?而且由于您可能已经根据实体在逻辑上划分了控制器,因此在其中添加这些 json 服务方法是有意义的,而不是专门为 web api 创建另一个类。

所以对于你的特殊情况(如果我理解正确的话),我会坚持使用控制器。


谢谢,我们创建 WebAPI 和控制器的方式有什么不同吗?
@flybyte 是的,您需要从 ApiController 派生,请参阅 asp.net/web-api/overview/getting-started-with-aspnet-web-api/…
Web Api 可以执行 JSON,以及您列出的其他方法。控制器不能(巧妙地)变成 API,所以鉴于用户有远见,我建议使用更具可扩展性/灵活性的解决方案。它不像老式的 WCF 服务,web api 通常既强大又灵活。因此,虽然您只需要简单的场景,但它不会妨碍您。但是,如果您需要它,您将拥有强大的力量
D
David Klempfner

答案归结为关注点分离、加快服务的创建以及依赖约定而不是配置。

控制器的主要职责是充当视图和模型之间的协调者,但 API 的主要职责是处理数据。在 API 约定的情况下,执行 CRUD 操作非常容易。下面是 CRUD 操作和 HTTP 操作之间的映射

获取:阅读

发布:创建

放置:更新

删除:删除

因此,使用 API,您不必创建单独的操作并使用 HTTP 操作对它们进行归因。


R
Ramon Chan

我对 ApiController 的唯一担忧是它是基于站点而不是基于区域的。一个站点只能有一个 apicontroller 子文件夹供您命名控制器方法。在某些情况下,您可能希望在不同区域复制控制器名称:

domain.com/api/area1/controller1/

domain.com/api/area2/controller1/

我记得有一些自定义代码设置可以做到这一点,但默认情况下它不起作用。


这似乎是评论,而不是答案。
不要真的你在说什么。如果您将控制器命名为 Area1XController,那么您可以这样做:domain.com/Area1X/1,创建一个控制器:Area2XController,然后通过 domain.com/Area2X/1 访问它。最大的问题是你为什么要这样做。区域名称是抽象的,它对用户没有任何意义。如果您有 4 个区域,那么最好使用功能用途名称。
R
R.H. Thorne

我同意肖恩威尔逊(最佳答案)的回答,但不知道为什么,因为我有点困惑,仍然试图理解以下(可能不正确)的预感 -

使用 WebAPI Controller 将 JSON 数据传递给客户端,以便客户端可以处理视图操作。这个过程不需要视图,而只是对任何调用方法(即javascript请求)的响应,以便客户端可以处理任何客户端操作。

当您需要在 page_load 期间或之后使用数据来操作视图时(即不适用于 SPA 应用程序),请使用 MVC 控制器。

你看,我只是不知道我在这里有什么不正确并且感到困惑,因为肖恩回答的最后一行指出“我使用 MVC 控制器来处理基本的浏览器路由和 SPA 的交付。” - 当我假设它可能是接收 JSON 格式响应的 JavaScript 方法时,也许我不完全知道什么是安静的客户端。这是 Stackoverflow 中最接近的帖子,它与我的问题的答案远程相关,所以我正在回答这个帖子,而不是可能重复问题。


“使用 MVC 控制器传递视图”您可以将 SPA 包装到 MVC 部分中以组合成视图。 ASP.NET MVC 开发人员应该理解这个概念。您可以在视图生成期间使用常规 Razor+ASP.NET 工具(例如服务器端处理)将 HTML+JS 呈现给客户端。许多开发人员在这里遇到的问题是静态 HTML+JS 文件并不是使 SPA 成为 SPA 的原因。有时内容需要是动态的,并且是针对用户的,但所有框架都倾向于偏离这一事实。 “SPA”和“MVC”并不相互排斥。
j
jezzipin

在这种情况下,我会推荐 WebApi,因为它非常适合基于 Javascript 请求传输此类数据。我通常会开发我的 WebApi 控制器,以便它们返回一个 JSON 友好的对象,然后我的 Javascript 可以轻松地对其进行解析。

如果您想生成一些 HTML 并用 Javascript 调用替换页面的各个部分,那么您唯一想要在 MVC 控制器上使用操作来完成此类事情的实时情况。

例如:

您有一个 JQuery UI Datepicker,它在选择时会生成一个单选按钮列表,这些单选按钮代表所选日期的事件。

在这种情况下,您可以使用 WebApi 返回一些 JSON,然后使用 Javascript 生成必要的 HTML,但通常使用 Javascript 创建大量 HTML 是不好的做法。让 C# 构建 HTML 然后通过部分视图返回它会更好,因为这样您就不太可能遇到 Javascript 解析错误。更不用说它使 HTML 更容易编写。