Разница между ApiController и контроллером в ASP.NET MVC

Question

Я играл с бета-версией ASP.NET MVC 4 и теперь вижу два типа контроллеров: ApiController и Controller.

Я немного смущен, в каких ситуациях я могу выбрать конкретный контроллер.

Для примера: Если я хочу вернуть представление, я должен использовать ApiController или обычный Controller? Я знаю, что WCF Web API теперь интегрирован с MVC.

С тех пор мы можем использовать оба контроллера, может кто-нибудь указать, в каких ситуациях идти за соответствующим контроллером.

Answer 1

Используйте контроллер, чтобы визуализировать ваши обычные взгляды. Действие ApiController возвращает только данные, которые сериализуются и отправляются клиенту.

here is the link

Цитата:

Примечание Если вы работали с ASP.NET MVC, то вы уже знакомы с контроллерами. Они работают аналогично в Web API, но контроллеры в Web API получают из класса ApiController вместо класса Controller. Первое существенное различие, которое вы заметите, заключается в том, что действия над контроллерами Web API не возвращают представления, они возвращают данные.

ApiControllers специализируются на возвращении данных. Например, они заботятся о прозрачной сериализации данных в формате, запрошенном клиентом. Кроме того, они следуют по другой схеме маршрутизации по умолчанию (как в: сопоставление URL-адресов с действиями), предоставляя API REST-ful по соглашению.

Возможно, вы могли бы что-либо использовать с помощью контроллера вместо ApiController с некоторым (?) Ручным кодированием. В конце концов, оба контроллера построены на основе ASP.NET. Но наличие REST-ful API сегодня является таким общим требованием, что WebAPI был создан для упрощения реализации такого API.

Это довольно просто решить между двумя: если вы пишете приложение на основе Интернета/интернет/интранет на основе HTML - возможно, при случайном вызове AJAX, возвращающем json здесь и там, - придерживайтесь MVC/Controller. Если вы хотите предоставить управляемый данными/REST-ful интерфейс для системы, перейдите в WebAPI. Вы можете комбинировать оба, конечно, с вызовами AJAX с ApiController caterpils с страницы MVC.

Чтобы привести пример реального мира: в настоящее время я работаю с системой ERP, которая предоставляет API REST-ful своим сущностям. Для этого API WebAPI будет хорошим кандидатом. В то же время система ERP предоставляет веб-приложение с высоким AJAX-кодом, которое можно использовать для создания запросов для API REST-ful. Сам веб-приложение может быть реализовано как приложение MVC, используя WebAPI для извлечения метаданных и т. Д.

Answer 2

Что вы предпочитаете писать и обслуживать?

ASP.NET MVC

public class TweetsController : Controller { 
    // GET: /Tweets/ 
    [HttpGet] 
    public ActionResult Index() { 
    return Json(Twitter.GetTweets(), JsonRequestBehavior.AllowGet); 
    } 
} 

ASP.NET Web API

public class TweetsController : ApiController { 
    // GET: /Api/Tweets/ 
    public List<Tweet> Get() { 
    return Twitter.GetTweets(); 
    } 
} 

Answer 3

Я люблю то, что MVC6 ASP.NET сердечника слили две модели в один, потому что я часто нужно поддерживать как миры.Хотя верно, что вы можете настроить любой стандартный MVC Controller (и/или разработать свои собственные классы ActionResult), чтобы действовать & ведут себя точно так же, как ApiController, его может быть очень сложно поддерживать и тестировать: кроме того, имея Контроллеры методы, возвращающие ActionResult, смешанные с другими, возвращающими исходные данные/сериализованные данные/IHttpActionResult, могут быть очень запутанными с точки зрения разработчика, особенно если вы не работаете в одиночку и должны заставить других разработчиков ускорить этот гибридный подход.

Лучшая методика, с которой я пришел до сих пор, чтобы свести к минимуму эту проблему в непрофильных веб-приложениях ASP.NET, заключается в том, чтобы импортировать (и правильно настроить) пакет веб-API в веб-приложение на основе MVC, поэтому я могу лучшее из обоих миров: Controllers для просмотров, ApiControllers для данных.

Для того, чтобы сделать это, вам нужно сделать следующее:

• Установите следующие пакеты Web API с помощью NuGet: Microsoft.AspNet.WebApi.Core и Microsoft.AspNet.WebApi.WebHost.
• Добавьте один или несколько ApiControllers в папку /Controllers/.
• Включить следующие WebApiConfig.cs файл в папку /App_Config/:

---

using System.Web.Http; 

public static class WebApiConfig 
{ 
    public static void Register(HttpConfiguration config) 
    { 
     // Web API routes 
     config.MapHttpAttributeRoutes(); 

     config.Routes.MapHttpRoute(
      name: "DefaultApi", 
      routeTemplate: "api/{controller}/{id}", 
      defaults: new { id = RouteParameter.Optional } 
     ); 
    } 
} 

Наконец, вам нужно зарегистрировать выше класс в Startup класса (либо Startup.cs или Global.asax.cs, в зависимости, если вы используете шаблон запуска OWIN или нет).

Startup.cs

public void Configuration(IAppBuilder app) 
{ 
    // Register Web API routing support before anything else 
    GlobalConfiguration.Configure(WebApiConfig.Register); 

    // The rest of your file goes there 
    // ... 
    AreaRegistration.RegisterAllAreas(); 
    FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters); 
    RouteConfig.RegisterRoutes(RouteTable.Routes); 
    BundleConfig.RegisterBundles(BundleTable.Bundles); 

    ConfigureAuth(app); 
    // ... 
} 

Global.asax.cs

protected void Application_Start() 
{ 
    // Register Web API routing support before anything else 
    GlobalConfiguration.Configure(WebApiConfig.Register); 

    // The rest of your file goes there 
    // ... 
    AreaRegistration.RegisterAllAreas(); 
    FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters); 
    RouteConfig.RegisterRoutes(RouteTable.Routes); 
    BundleConfig.RegisterBundles(BundleTable.Bundles); 
    // ... 
} 

Этот подход - вместе с его преимущества и недостатки - далее объяснено в the following post.

Answer 4

Каждый метод в Web API возвращает данные (JSON) без сериализации.

Однако, чтобы вернуть данные JSON Data в контроллерах MVC, мы установим возвращаемый тип результата действия в JsonResult и вызовите метод Json на нашем объекте, чтобы убедиться, что он упакован в JSON.