Should Asp.net pages have codebehind files in MVC

My web application is an Asp.Net MVC pattern. None of the .aspx pages have code behind files. I was told that since the application follows MVC pattern, the .aspx pages don't have a codebehind file. All the C# coding is done inline.

My question is that, is it that we shouldn't have code behind files for .aspx pages if we follow MVC pattern. I don't see any difference between these .aspx pages and traditional ASP pages where we do inline coding. In order to take advantage of Asp.Net and maitaining the code / html shouldn't we have a code behind file for every .aspx page?

It would be great if someone could clearly explain this.

Thanks in advance.

Asp.net MVC doesn't use codebehinds that's true. But. You shouldn't think of your pages as traditional ASP pages, because they're not. Majority of processing (as in codebehind) is done inside controller actions. ASPX pages barely display results of that processing (when action result is ViewResult or PartialViewResult).

So we could say that controller actions "are" codebehinds for many ASPX files.

That's of course a very broad simplification of this, but you could understand it this way.

Additional explanation

You may argue that writing C# code in an ASPX file is very similar to writing ASP code, but let me make you think of it for a moment. In Asp.net WebForms whenever you added

<asp:Repeater ... />

what you basically did, was a foreach statement in a different form with some additional capabilities. In Asp.net MVC what you write is an actual foreach statement instead with any additional functionality that you want. Majority of time you'll just render items without additional functionality so foreach will be:

1. faster than rich server-side control
2. simpler, because HTML rendered for each item will be approx. the same as repeater item's template
3. less resource hungry, because it's just a simple language construct and not some server-side control that has to be instantiated, executed and saved (as in state)

Why can a controller action be a codebehind for many ASPXs?

Because we can have this kind of code

public ActionResult Index()
{
    var data = /* get some data */
    if (data.Count > 0)
    {
        /* first ASPX */
        return View("DisplayItems", data);
    }
    else
    {
        /* second ASPX */
        result View("DisplayEmpty");
    }
}

Not to even mention that what this code does is so much simpler than some complex page lifecycle processing that would need to handle both states which would lead to much more complex ASPX file having all the HTML.

In Asp.net MVC code is very simple/basic because it only does what it needs to do and views are much simpler just as well, because each may only serve one single state/situation/purpose. No multifaceting as in Asp.net WebForms.

None of the .aspx pages have code behind files

That's how it should be. The traditional code behind in WebForms where you subscribe for different events of the page life cycle no longer should be done in MVC. This task is done by the controller. Your .aspx pages could of course contain some inline server side code in order to use HTML and Url helpers such as TextBoxFor, EditorFor, ActionLink, ... But that's where you should limit your views to.

Let's take for example another view engine such as Razor. The notion of code behind doesn't even exist for it. So the fact that you could still have code behind in the WebForms view engine is because it is a legacy heritage from classic ASP.NET WebForms, not to be used in MVC.

There are no code behinds in MVC. MVC is just using aspx just as a templating engine (probably to get a release out fast, because they are now shifting to Razor as their preferred templating engine)

No views should not have code behind files (be it webforms viewengine or razor viewengine). The essence of mvc is that you should never have any logic in views and they should be dumb on most part. At most you can use looping (Many people use Editor templates to avoid looping) and conditional statements to render HTML conditionally. So, when you have no logic in views there is no need of code behind at all. Every thing in Model should be set when controls your views. If you think there is view specific logic