Editorial: Selecting a .NET Web Framework

Posted by Jonathan Allen on Jan 15, 2008

Sections

Process & Practices,

Development

Topics

Agile ,

Web Frameworks

Tags

MVC ,

ASP.NET

In the past selecting a web framework for .NET languages was a non-issue. Your choice was between pure ASP.NET or a hybrid design that mixed classic ASP with ASP.NET. And even that was seen as a temporary hack rather than a conscious choice. But once that was done, you have to choose between C# or VB.

Look at any other platform and the situation is practically reversed. You start with a language, be that Java, Ruby, Python, Smalltalk, etc., and each has easily a dozen language-specific frameworks. By settling on a non-.NET platform, you have given up the ability to leverage multiple languages and gained the ability to select the right web framework for you.

Now so far I have been ignoring the fringe stuff like MonoRail. I do this because most .NET developers ignore them as well. There simply are not enough people using these frameworks to justify vendor or open source support. It is hard to overstate the huge library of controls and templates available to ASP.NET developers. No other .NET web framework comes anywhere near.

In fact, one could probably get away with saying that no other web framework for any platform comes close. Some, like Ruby on Rails, were just beginning to introduce the concept of controls or "widgets" in 2006.

But things are changing in the Microsoft world. Ruby on Rails, MonoRail and other MVC projects like it haven't been completely ignored. The cries of jealous .NET developers have been heard and Microsoft is developing a MVC framework for ASP.NET that completely discards the old WebForms model.

With this comes a hard choice. Do you give up your control libraries, both the ones you developed internally and those you bought, in order to gain the advantages of MVC? Is getting rid of the twin evils of view state and naming containers worth starting over on everything else?

1. Back to top

   Meh, depends.

   by Nicholas Piasecki

   The company that I work for (www.skiviez.com -- a men's underwear store, technically safe for work but takes some people by surprise) uses MonoRail. It was a good match for our site, which is not large or terribly complex by any means. It was a rewrite this past summer of an aging clusterfark of classic ASP pages. MonoRail (RC2 at that time) had bugs and quirks, but in general the development was painless, particularly for developers who were coming from classic ASP and PHP. We could control the HTML exactly and we could avoid the complexity of the WebForms model. Now that ASP.NET MVC is on the horizon, I think that we'd have a tougher time choosing a framework than we did 6 months ago.
   
   WebForms, IMHO, is great for Web *applications* (need complex controls? drag and drop those components, yay!) and corporate intranet type sites with complex interactions (e.g., SharePoint plug-ins and such), but it is not so hot for public-facing Web sites, because (gross generalization ahead, and we'll use our site as an example) public-facing Web sites are usually not completely full of forms and do not require spectacularly complex controls. So, avoid the overhead and complexity with an MVC framework. You still get the power of the ASP.NET pipeline and libraries (forms authentication, caching, etc.) without worrying about events and handlers and databindings for a medium that consists of basically just passing arrays of strings back and forth. If the site itself doesn't need to be complicated, let's not use a complicated framework, either.
   
   If you read between the lines, though, we went with MonoRail because MVC was familiar to us. We had no investment in WebForms and, after evaluating it, really didn't care to spend the time learning its intricacies. But if you are at a whole company that is deeply invested in WebForms and you have developers who enjoy using and working with WebForms, then why abandon something that works? I don't think ASP.NET MVC is necessarily a mulligan on WebForms, just a recognition that WebForms is not suited for every type of site on the Web.
   
   Just my two cents!

   Reply

2. Back to top

   Is that really how people see the .NET ecosystem?

   by Francois Ward

   I've been in the .NET world since .NET 1.0's beta, and in ASP.NET since not long after that. (Almost) no scerious projects will use "plain ol webforms". They simply don't get the job done. The templating engine and the webform architecture is great, but its too "plain".
   
   MonoRail actually is semi-popular. The Web Client Software Factory and other MVP (Model View Presenter pattern) is actually quite popular, and MVP is definately the way to go to make pure ASP.NET apps modular and testable, and its quite the common approach (and many will argue: better than MVC). There has been other semi-mainstream methodologies, such as the application blocks from microsoft.
   
   I guess the misconception comes a lot from how many people came from Java/Strut(or others) early on, not seeing any MVC, thinking there was "nothing" (when MVP has been a recommendation for a while), but if you get hook with a serious project, the odds are good there's some kind of web framework behind it. It is not AS diverse as in other languages, since there's already a semi-complete foundation (the web forms), and thus you don't need to build as much on top of it (as opposed to JSP, that some even completly replace, or a cgi/bin language, which potentialy had nothing at first), but using pure asp.net web forms was never really the answer for anything beyond prototypes...
   
   And the way I see it, MS's ASP.NET MVC is more of a path for people coming from non-.NET world than anything else, as webforms + MVP add a lot that you won't get in an MVC, but Microsoft wouldn't want to alienate potential customers :)

   Reply

• Older >