How to Move from Web Forms to ASP.NET MVC 5

asp.net-mvcmvc

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?

Best Answer

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. There is no SESSION; you'll have to live without it. 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.

Related Topic