在ASP.NET MVC ApiController和控制器之间的区别 [英] Difference between ApiController and Controller in ASP.NET MVC

问题描述

我一直在ASP.NET MVC 4 beta中打转转，我现在看到的控制器两种类型： ApiController 和控制器。

I've been playing around with ASP.NET MVC 4 beta and I see two types of controllers now: ApiController and Controller.

我在什么情况下我可以选择一个特定的控制器有点困惑。

I'm little confused at what situations I can choose a particular controller.

有关恩：如果我想返回一个观点，我已经使用 ApiController 或普通的控制器 ？我知道，WCF的Web API现在与MVC集成。

For ex: If I want to return a view then I've to use ApiController or the ordinary Controller? I'm aware that the WCF Web API is now integrated with MVC.

由于现在我们可以使用两个控制器可有人请指向哪些情况去相应的控制器。

Since now we can use both controllers can somebody please point at which situations to go for the corresponding controller.

推荐答案

使用控制器来呈现你的正常的看法。 ApiController操作只返回数据是串行化并将其发送到客户端。

Use Controller to render your normal views. ApiController action only return data that is serialized and sent to the client.

<一个href=\"http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api\">here是链接

here is the link

报价：

请注意如果您已经在ASP.NET MVC的工作，那么你已经熟悉控制器。他们的Web API类似的工作，但在网页API控制器从ApiController类而不是控制器类派生。你会注意到的第一个主要区别是，基于Web API控制器动作不返回的意见，他们返回数据。

Note If you have worked with ASP.NET MVC, then you are already familiar with controllers. They work similarly in Web API, but controllers in Web API derive from the ApiController class instead of Controller class. The first major difference you will notice is that actions on Web API controllers do not return views, they return data.

ApiControllers是专门返回数据。例如，他们采取的数据透明序列到由客户端请求的格式的照顾。此外，他们遵循默认情况下，不同的路由方案（如：URL映射到动作），按照惯例提供一个REST API FUL。

ApiControllers are specialized in returning data. For example, they take care of transparently serializing the data into the format requested by the client. Also, they follow a different routing scheme by default (as in: mapping URLs to actions), providing a REST-ful API by convention.

您可以使用一个控制器，而不是用一些（？）手工编码的ApiController可能做任何事情。最后，两个控制器建立在ASP.NET的基础。但有一个REST的API FUL是这样一​​个共同的要求，今天的WebAPI的建立是为了简化这样的API的实现。

You could probably do anything using a Controller instead of an ApiController with the some(?) manual coding. In the end, both controllers build upon the ASP.NET foundation. But having a REST-ful API is such a common requirement today that WebAPI was created to simplify the implementation of a such an API.

这是相当简单的在两者之间做出决定：如果你正在写一个HTML的基于Web / Internet / Intranet的应用程序 - 也许，偶尔AJAX调用返回JSON在这里和那里 - 坚持MVC /控制器。如果你想提供驱动/ REST-FUL接口与系统中的数据，一起去的WebAPI。您可以结合两者，当然，有一个ApiController迎合AJAX从MVC页面调用。

It's fairly simple to decide between the two: if you're writing an HTML based web/internet/intranet application - maybe with the occasional AJAX call returning json here and there - stick with MVC/Controller. If you want to provide a data driven/REST-ful interface to a system, go with WebAPI. You can combine both, of course, having an ApiController cater AJAX calls from an MVC page.

要给出一个真实的例子：我目前正在与ERP系统，提供一个REST API FUL对其实体工作。对于这个API，的WebAPI将是一个不错的人选。同时，ERP系统提供了可用于创建为REST-FUL API查询高度AJAX形式的web应用程序。 Web应用程序本身可以实现为MVC应用程序，利用的WebAPI的抓取元数据等

To give a real world example: I'm currently working with an ERP system that provides a REST-ful API to its entities. For this API, WebAPI would be a good candidate. At the same time, the ERP system provides a highly AJAX-ified web application that you can use to create queries for the REST-ful API. The web application itself could be implemented as an MVC application, making use of the WebAPI to fetch meta-data etc.

这篇关于在ASP.NET MVC ApiController和控制器之间的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！