As you probably know, they put out Release Candidate 2 for the Microsoft ASP.NET MVC Framework. This is particularly interesting to me, because at work we’re working on re-write design of a pretty large legacy ASP application. Amongst other questions – the question came up: “Do we use post-back/code-behind or the rest/mvc pattern for this site?”.
It’s definitely a legitimate question.
So Microsoft made the strategic decision back before .NET 1.0 (2001) that they were going to go with the post-back model, which definitely has it’s pros and cons. And for the cons, well, they’ve mostly been taken care of (I think). However, the MVC pattern has existed for a long time and has been popular with Java, Flex, RoR, etc for quite some time – and for good reason, it’s a very good pattern!
MVC in a nutshell:
Let me warn you – if you are firmly grounded in ASP.NET, there are some things you immediately won’t like – but hopefully I can address those and put this into perspective. First, what is MVC? It stands for Model-View-Controller. It’s a pattern of how to: lay out your website, how to process pages, how to manage page-state and offers a fundamentally better way to manage the code for a website. One of the driving principles behind this pattern is to make a website very unit test-friendly. The “controller” takes care of getting the data from the “model”, and there is typically a “view” – which is the actual .aspx page that renders the content. So the URL no longer matches up to the actual page name. Instead of /ProductDetail.aspx?productId=3 you would have something like /Products/Detail/3 for a URL.
The Pros for MVC for ASP.NET:
- Makes it almost obvious and easy to have unit tests for an entire website, except for the very thin layer that renders the actual HTML. Supports and encourages TDD.
- Forces the developer to have a clear separation between routing, data sources and UI presentation. On a bigger site, this could lead to a significantly easier website to manage.
- Can be significantly faster than post-back and potentially more scalable.
- Great for simple websites and simple controls – or for managing web content.
The things that are a wash for ASP.NET, but great for other technologies:
- Can use the Controllers to also render RESTful web services – assuming you have to render these by hand. This particularly feature would never get used in a .NET environment, because WCF renders REST for us.
The Cons for MVC for ASP.NET:
- Related to the first item, you lose ControlState and ViewState. This means if you want to keep track of the values that are in textboxes, dropdowns, etc – you have to roll your own way to do this.
- Learning curve/momentum: this is really bleeding-edge, in terms of support, websites that talk about it, people who know it (on the ASP.NET platform), etc. There are millions of pages dedicated to post-back right now. So until MVC gains more momentum, not only is it a learning curve, there is not a whole lot of help on the ‘net for it at the moment.
My Conclusion (as of MVC RC2 – because it will likely change, when future releases come out!):
I would almost guarantee that Microsoft will go in this direction/is going in this direction. ASP.NET MVC is being touted as an “alternative” to post-back until it gains momentum, I would assume. This is a fundamentally better way to build a website.
So – my guess and my feel is that Microsoft is already aware of this – and can only do so much, so fast. I would almost bet money, that Microsoft would come out with MVC-compatible ways to handle GridViews, TreeViews, etc relatively soon – as it’s not a big stretch to make them work. Although I haven’t built my own controls – from what I read, instead of doing a post-back, you can do the post-backs for these types of controls back to a specific MVC Controller, which will take care of getting the correct data for you. My guess is that it wouldn’t be too big of a deal to come out with MVC versions of GridView, TreeView, etc?
In short, my prediction is ASP.NET MVC will completely replace postback in whatever version is coming after Visual Studio 2010. And right now, it’s not ready – for any real application. The question is, when will they take up the slack on showstoppers listed above? Because then – is when the MVC movement will begin IMHO!