Why derive from ControllerBase vs Controller for ASP.NET Core Web API?

C#asp.netasp.net Web-Apiasp.net Core

C# Problem Overview


I am following this tutorial for creating an ASP.NET Core Web API, and in the section on adding a controller, the tutorial gives code to replace the template code for a controller. One of the things that really caught my eye was that in the template code, I get:

TodoController : Controller

Then in the tutorial code I'm supposed to use instead of that, I find:

[Route("api/[controller]")]
[ApiController]
TodoController : ControllerBase

I'm very interested to know why it is necessary to derive from ControllerBase instead of Controller for a Web API controller. Why is this done?

C# Solutions


Solution 1 - C#

> why it is necessary to derive from ControllerBase instead of Controller for a Web API controller.

It is not strictly necessary, just more to the point. The Controller class derives from ControllerBase and adds some members that are only needed to support Views.

Basically:

public abstract class Controller : ControllerBase
{
    public dynamic ViewBag { get; }
    public virtual ViewResult View(object model) { }
    // more View support stuff
}

When you write an API then ControllerBase matches your requirements better but both will work.

Per the documentation (emphasis mine):

> Don't create a web API controller by deriving from the Controller class. Controller derives from ControllerBase and adds support for views, so it's for handling web pages, not web API requests. There's an exception to this rule: if you plan to use the same controller for both views and web APIs, derive it from Controller.

I seem to remember that there was no ControllerBase in the first MVC iterations, it was inserted later. Hence the slightly odd naming/inheritance structure.

Solution 2 - C#

FROM https://docs.microsoft.com/en-us/aspnet/core/web-api/?view=aspnetcore-3.1

Don't create a web API controller by deriving from the Controller class. Controller derives from ControllerBase and adds support for views, so it's for handling web pages, not web API requests.

Solution 3 - C#

One other important difference is that ControllerBase is abstract class that's why it doesn't implement Dispose method. So you need to handle yourself. see this SO entry

Solution 4 - C#

ControllerBase abstract class

> Controller abstract class derives from ControllerBase abstract class therefore supports to Create views ,API Not Advice to Create Views .

ControllerBase abstract class has Member[Properties,Methods] without Implementaion Like

public abstract class ControllerBase{
        public HttpResponse Response { get; }
        public HttpRequest Request { get; }
        public HttpContext HttpContext { get; }
        public virtual RedirectToActionResult RedirectToAction(string actionName);}

> ControllerBase has all Request and Response between Client-side and > Server-side


Controller abstract class

> Controller abstract class Enables us To Create Views to display Data > in client-side, it derives from ControllerBase abstract class.

public abstract class Controller : ControllerBase{
        public dynamic ViewBag { get; }
        
        public ViewDataDictionary ViewData { get; set; }
       
        public ITempDataDictionary TempData { get; set; }
}

https://newbedev.com/why-derive-from-controllerbase-vs-controller-for-asp-net-core-web-api

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionProfKView Question on Stackoverflow
Solution 1 - C#Henk HoltermanView Answer on Stackoverflow
Solution 2 - C#MarkView Answer on Stackoverflow
Solution 3 - C#EmilView Answer on Stackoverflow
Solution 4 - C#Ragab MohamadView Answer on Stackoverflow