From the blog: "What are other developers building with .net?". Introducing BuiltWithDot.Net

Is mvc hurting your brain? 3 reasons to embrace the new hotness.


You're struggling to wrap your head around what has happened to since you embraced webforms. You've done amazing things with webforms and you're still very comfortable using it. But it's 2018, and you know it.

by Corstiaan Hesselink

Last updated: Friday May 25, 2018Reading time: 6 minutes

You’ve looked at mvc a couple times but in comparison with webforms it feels like you need to understand more. You don’t know where to start. It can be perplexing. You’re disappointed with mvc making your job more complicated than before. You want to feel like you can build a website as easily as you did before but with the new “hotness”.

Let’s start by unpacking 3 important reasons why moving to mvc is a good idea. No code examples or hours of difficult to process information. No brain pain. I promise. Just the good stuff.

1. Blazing performance, happy users

The goal of webforms was to make web development feel more like desktop development. Sounds good on paper but it’s not so good in real life. A desktop application has state while the web is state-less. In other words, a desktop app knows what’s going on at all times, while a web app knows about the user’s behaviour only during a single response-request cycle. After the request has been served with a response a web app is in the dark about what the user is up to.

To cross this divide the webforms team came up with the notorious… ViewState (dramatic sound effect). ViewState basically crams all the state data into a hidden form field and reads this data between postback’s, creating the illusion that the app has something sort-of resembling “state”. If you’re new to webforms, you might not even know that it’s there. But it’s lurking inside your html like a 800 pound gorilla in cammo (still working on my references, obviously).

Although it’s easy to see how ViewState was designed to make your life as a developer easier, it has come at a great cost: performance. The amount of data living inside the hidden form field in your app’s html could get as large as 5mb! That’s 5 mb of data that has to go back and forth over the wire on EVERY postback. The ViewSate has to be processed also (encrypted, etc) which also adds to the total response time.

A large ViewState is just plain awful. It drags down the user experience with slow loading pages and, if you’re running an app that is remotely popular, that extra ViewState can really count towards your bandwidth bill. It’s like having to buy extra luggage allowance on EVERY flight you take, for the rest of your life.

Can we just try to keep the ViewState size under control, you say? Short answer: no, you can’t. And you shouldn’t want to either. ViewState has been a well intended experiment but it has not place on the modern web. It causes more problems than it aims to solve and trying to work with those problems is like unpacking a russian doll. There’s always some new thing to worry about. Mvc has no ViewState and thus none of it’s trappings. Just by itself this is good reason to go with mvc over webforms.

2. Full control over your app’s html

So, webforms idea was to make web dev more like desktop dev. Server controls exist for the same reason. They’re the shiny drag-n-drop-able things that you can lob onto a page. If “write-zero-code” is the drug then server controls are the dealers. Server controls are a great idea but just like ViewState, server controls come with a few pretty nasty side effects and a terrible hangover.

Server controls have their html build into them. This means that when you drag a server control onto a form inside Visual Studio, the html that gets rendered and output to the user is hidden during development. If this is one of the things you like about webforms, then mvc will be painful. Alot of under the hood magic is required to make this happen. But being in control of the rendered html is worth the effort, even though you need to knuckle down and push through the learning curve.

“So, why would I want 100% control over my app’s html output?” Well, why would you not want 100% control over your app’s html output? All things front-end become ALOT easier when you are the master of your app’s html. Working with attributes like classes and id’s, styling elements, interacting with those elements using javascript. This list goes on. Well, not really. Those were the 3 most important ones. But you get the point. Webforms get in your html’s way pretty much 100% of the time. Views (the V in mVc) give you super powers when it comes making your app’s html do your bidding.

Not having your finger on your app’s html pulse also encourages bad coding practices. Inline styling for example, using the attributes on the server controls (TextColor, BorderColor…). Yikes.

3. Test like a pro

To be fair, you can unit test your webform app’s code. The only thing you need to do is move all your code-behind logic to some other class, refactor that logic into chunks that make sense and then you can start writing tests. No problemo… Well, big problemo actually. This reduces your code-behind into a class that only handles the events of your app. Kinda what the Controller (the C in mvC) does. But the controller is designed to do exactly that, both within the context of your app as well as within the mvc model in general. It’s logical instead of hackey.

You need some discipline when coding your app regardless of the architecture you are using, to ensure your app is easy to test. That said, webforms makes it easy to adopt bad habits. Mvc encourages healthy coding behavior, and that’s what you should aim for.

When you get more into mvc you’ll find out that it’s unwise to cram your controllers full of logic instead of moving it to a more logical place (like a service object) if your goal is to have good test coverage. But let’s not worry about that yet.

All aboard the mvc train?

Mvc is by no means a silver bullet. Life knows no right or wrong. It’s a series of trade offs. Technology is no different. IMO these are 3 compelling reasons to get into mvc. As a developer, you should be in control of your tools. Deep down you know this is true.

Never miss an update!

Be the first to discover new articles just like this one. Delivered directly to your inbox, with my no-spam-guarantee™. Unsubscribe any time.