Web development in the .NET world has gotten a lot more interesting in the last couple of years. A few years ago, the only choice we had for a web front-end was ASP.NET WebForms. Nowadays you can add ASP.NET MVC and Silverlight to the mix. Obviously each option has its pro’s and con’s, so it’s not always clear which option should be used when you’re starting to build a new Web application.
Let’s start with ASP.NET WebForms. This is the option that has been available since the .NET platform was introduced, so there are already a lot of people experienced with it. There is also a ton of information available about the ins and outs of WebForms. And when it comes to commercial tool vendor support, it’s clearly miles ahead of the other options since there are lots of commercially supported controls available for it. Unfortunately, WebForms was originally created to offer a similar development model to WinForms developers. The code-behind files and the event-driven way of working is very similar to how you would write code in WinForms applications. Obviously, web applications and windows applications are completely different things, so you can’t reasonably expect the same way of working to be suitable for both.
Particularly, the Page and Control lifecycles are rather complex (at least much more complex than i would think they’d need to be) and often cause weird issues on complex pages. The event-driven model of both the Page class and the Control class (and its derivatives) seem to be the major cause of this. I think most WebForms developers have on more than one occasion spent long times debugging weird situations which were ultimately related to certain events triggering unexpected behavior in other controls on the same page. Granted, people with an in-depth knowledge of how these lifecycles really work don’t run into this as much, or are capable of avoiding these problems altogether.
You could indeed make the argument that most of the problems that people are experiencing with WebForms are caused by those people’s lack of understanding how it really works and how it really should be done. On the other hand, that is a pretty good sign that WebForms development isn’t intuitive or clear enough, and that while Microsoft has tried hard to make it easy to use, most people seem to solve their WebForms problems by hacking around their problems, or playing around with settings until it seems to work.
Another major problem with WebForms is that it doesn’t easily enable Test Driven Development. True, there are various patterns you can use to make sure you can write testable UI logic (up to a certain point anyway) but all in all, these approaches require more effort than should be necessary and you often end up wrapping a lot of stuff just to be able to test it. WebForms in general was never designed with testability in mind, and you will most definitely be confronted with that if you try to write testable UI code with WebForms.
As you can probably tell, i’m not a huge fan of WebForms. I think it’s fine for simple applications, but for anything beyond that i’d like to avoid it as much as possible.
Microsoft’s upcoming ASP.NET MVC framework aims to fix much of the issues i’ve mentioned above. It was designed with testability in mind, and although it’s not perfect either (depending on who you ask), it is certainly a huge improvement over WebForms when it comes to writing testable UI code. You also have a lot more options when it comes to having the framework behave the way you’d like it to. Another important benefit is the fact that ASP.NET MVC kinda forces you to structure your code in a much more sane manner. You put as little logic as possible in the views, and you put most of it in the Controllers where it belongs. Obviously, that doesn’t mean you should put business logic in the Controllers!
One of the downsides of ASP.NET MVC is that, due to its completely different way of working compared to WebForms, it comes with a much higher learning curve. Experienced WebForms developers might struggle with it at first, and might even be frustrated because most of their hard-earned WebForms experience no longer gives them a benefit. Some will probably enjoy it much more than WebForms, and some will probably dislike it strongly because it’s so different. Another downside is that there are far less commercial tool vendors that are offering ASP.NET MVC controls, at least compared to WebForms. Although that might not be that big of an issue, since i suspect that it’s easier to develop nice looking and reusable controls yourself when using ASP.NET MVC than it is to do so when using WebForms.
If you’re starting out with ASP.NET MVC, i think it’s safe to assume that you won’t proceed as quickly as you’re used to at first. But once you’re used to the new way of working, i’m pretty sure that it enables you to rapidly implement new pages and new functionality in a very clean way. For true web applications, i would probably pick ASP.NET MVC everytime, unless you don’t have the room to get over the learning curve. Also, when combined with a client-side javascript library like JQuery, this approach seems very compelling. Yes, i know you can use JQuery with WebForms as well, but it just seems to lend itself better to the MVC approach.
And then there’s Silverlight. There are already a couple of reasons why people would not want to use Silverlight for web applications. For starters, even though the application is running in a browser, it’s not really a true web application is it? Your users can’t bookmark pages, using the back button leads to unexpected behavior, there aren’t that many options for Search Engine Optimization, etc… However, if your only web-related requirement is that your application needs to run in a browser, without having to worry about any of the typical expected requirements for web applications, then Silverlight is a pretty interesting choice as well. You can very easily create very rich applications, with possibilities that are either impossible, or extremely difficult to do with typical web development platforms.
Our Genesis web front-end is developed in Silverlight. The UI not only looks great, but you can navigate between all of the available data in a manner that is simply much easier to develop than it would be for typical web apps. It’s very easy to create that ‘wow’-effect with your users in Silverlight. Obviously, that ‘wow’-effect isn’t the most important part of your application, but it does count for something.
Another interesting aspect of Silverlight development is that you can go back to a more statefull development model compared to the typically stateless nature of web aplications. After all, the cost of that state is no longer something your web server has to bear. It’s now the client who has to keep that state around, so you can avoid a few extra roundtrips here and there as well. Then again, you really don’t want your Silverlight application using huge amounts of RAM in your user’s browser either so you do need to take care not to go overboard with it. The development model is completely different than both WebForms and ASP.NET MVC, but if you already have people with WPF experience the learning curve is probably not that high.
However, testability isn’t great (yet) when it comes to Silverlight. It’s possible to write testable code, and you can execute tests in the Silverlight runtime, but it doesn’t really lend itself to a true TDD approach yet although i hope that will improve in the future.
So there you have it… the three options for .NET web development. I’d stay away from WebForms altogether from now on, and i’d decide between ASP.NET MVC and Silverlight on a case by case basis. What, you weren’t hoping for a definitive answer were you? 
I would be interested in hearing your thoughts about pro’s and con’s of any of the options… particularly things that i haven’t mentioned, or if you just plain disagree with my statements. Which option would you prefer to use, or not to use?
Loading ...
