I've been using Web Forms for way too long now and I want to switch to ASP .NET MVC 5 because I think that it's the "next step" for a ASP .NET developer. I also find it to generate pages a lot faster and provide better control over the HTML, but I feel like the concept is physically too big to grasp. This is my main bugbear and I just feel like I need some sort of resource or something to read to fully understand the flow of pages in ASP .NET MVC.

The ASP .NET MVC Controllers are almost magical. Not magical as in "oh wow", but magical as in "how does something that the Controller returns possibly equate into usable HTML?" I mean things like this:

          // GET: tablename/Create
    public ActionResult Create()
        return View();

When does this code get fired? While web forms was, from what I've read, offensive to the HTML/HTTP concept (that is, the event based stuff didn't really fit well to the idea of a web page), with things like Page_Load it was easy to know what happens when and why. Say I have a label on the Create page, and I want to bind that to something in the database, do I update the controller to pass through that text and then bind to it in the View?

I found it easier to switch from VB.NET to C# than I have to switch from Web Forms to ASP .NET MVC. I have moments where I'm really impressed with ASP .NET MVC, when my pages load really quickly or when the data annotations automatically show up when I'm trying to update or insert. But I just can't envisage the flow from actually pressing a button on a web page and what happens in that lifecycle. In Web Forms this would happen in code behind, on a line by line basis, and Business Logic could be abstracted out into different classes. But in MVC, the View submits the information back to the controller, the controller sends through the database update, and then returns something back to web browser?

I'm not writing this to champion Web Forms in any which way shape or form, obviously it is an older tech, and I can understand why ASP .NET MVC is a better way. It's like ASP .NET MVC is forcing me to be a better developer, which is good, but for someone who is teaching themselves this tech, I am finding it profoundly difficult.

Am I missing something? Is there an easier way for me to learn how to switch from my Web Forms mentality to the MVC mentality?

  • 1
    To be fair, it is tagged as asp.net-mvc, and it would be a reasonable assumption that I was going from Web Forms to ASP .NET MVC (as Web Forms is a Microsoft technology). I can't picture many people going from Web Forms to PHP MVC implementation (but then again, you never know I guess). Commented Sep 16, 2016 at 2:53
  • @CandiedOrange "It's an architectural pattern" I think part of my problem is that I'm trying to learn the ins and outs of this pattern, while also learning how ASP NET MVC 5 handles this particular implementation Commented Sep 16, 2016 at 2:55
  • 3
    Both WebForms and ASP.NET MVC rely upon a set of assumptions and default configurations that a coder must understand in order to properly use the framework. WebForms with its "page life cycle" is only intuitive to you because you've gotten used to it. There's less magic/voodoo with MVC than with WebForms, once you get into the guts of it. I can debug into a custom model-binder, for instance, to see exactly how the framework translates HTML Form Inputs into a parameter class in my controller.
    – GHP
    Commented Sep 16, 2016 at 14:36

1 Answer 1


You're going to have to embrace ASP.NET MVC in its own right.

There is no server code-behind. There are no drag-and-drop widgets, no plugins, and no leaky page life-cycle. There is no almost-wysiwyg: instead there is total, actual, complete wysiwyg. You can still have SESSION variables, but you will need them far less. There's no weird, busted markup. Best of all, there's no lies or deception: ASP.NET MVC embraces the web just the way it is, instead of pretending to be something else.

All of this is good news.

My advice?

  • Start thinking about everything as a CRUD operation, a series of user transactions. That mindset won't get you completely there, but it will go a long way towards MVC enlightenment. Serve a page, get a result. Serve another page, get another result. Save the result to a database. Serve a new page containing database data. Rinse and repeat.

  • Understand the importance of Model-View-Controller. Make views stupid. Make controllers thin. All of your actual logic goes in the Model, which becomes fat. Use ViewModels if you need them to separate View logic from Model logic.

  • The Controller is a patch panel, a railway switchyard. Treat it as such.

  • Get really good at working with simple HTML/CSS and Javascript. Then learn how to fill forms with ASP.NET MVC's donut holes (most likely you'll be using Razor to do that).

  • Learn Server-Side Views first. Then, discover the essential truth of ASP.NET MVC, that it can serve more than just views, and become enlightened. It can serve files. It can act as a web service, and serve JSON to a SPA framework like Angular, instead of serving views. It can do this better (and simpler) than its predecessor, WCF, ever could.

  • Does my model really become fat? I didn't think that was a great place to put my business logic (unless you're saying I should put them in ViewModels which would make more sense). EDIT: Actually I could put them in their seperate classes for reusability. Commented Sep 28, 2016 at 3:11
  • 2
    The model is precisely where you should put your business logic. ViewModels have a different purpose. Commented Sep 28, 2016 at 3:52
  • Thank you for taking the time to flesh this out, you're really helping me to build higher quality web apps and be a better programmer all round... however on that topic, would you say that there are differing opinions on where to put what? I've heard it said that some people pack their controllers full of business logic. From what you're saying, that's not a good idea. But I guess, with MVC, you could write the whole thing in @ snippets in the cshtml. It would be really bad, obviously. But there seems to be more freedom, including the freedom to do whatever you want (even if thats bad). Commented Sep 28, 2016 at 4:01
  • The controller's purpose is to decide which methods to call and what to return from those methods to the UI (if anything), and that's all it does. In support of that purpose, it might do a bit of security filtering, but not much more than that. The controller is not required to do anything else. Commented Sep 28, 2016 at 6:03
  • Cool. Is it okay if, in the early days, I abstract all my decision making business logic into a separate class and then just use the Model to define new class types and what members they contain? Or is this just pointlessly extending the development with no real benefit. Commented Sep 29, 2016 at 1:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.