You’ve looked at asp.net 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 asp.net 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.
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 (
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 asp.net mvc. As a developer, you should be in control of your tools. Deep down you know this is true.