Buzz on ASP.NET MVC

Some intersting remarks that I came to read on ASP.NET MVC from the web are put here. These remarks are mostly about the why we need MVC and not how MVC can be done in ASP.NET

I think that the ASP.NET MVC as more natural way than Webforms to devolop web apps because it accepts the facts about http & TCP/IP. It should be the technology that should be in the place of ASP.NET Webforms and I wonder if it were in the place of WebForms how matured it will be by now. Why Microsoft is late to introduce this in webdevolopement. If one is choosing ASP.NET MVC as their way to devolop web apps I think it's wise to choose Ruby On Rails because it much more matured than ASP.NET MVC.

Here are some remarks which are really thought provoking on ASP.NET MVC

From here

1. the biggest architectural difference between MVC and WebForms is how they work with the stateless environment of the web: WebForms works hard to build a set of abstractions that hide the stateless nature of web programming, whereas MVC embraces the stateless environment and works with it.


From Scott Hanselmans blog comments
1. The thing that I love about this blog post is that you're addressing the why of ASP.NET MVC. There's a lot of how out there, and no clear explanation of why you should look into this raw version. I think it's crucial to get this message out to the those ASP.NET devs that haven't fully grok the power of ASP.NET as a platform, not just a control framework.

2. somehow people are "forced" to use postback/viewstate model when that is in fact not the case at all.

3. I think at its core it is a shift in thinking where behavior comes first, and visual presentation second. This is reversed in a page/view first approach and makes agile development more difficult.

4. MVC acknowledges that the web is stateless, that there is no such thing as a button click event on the server and that it's all request/response. WebForms wouldn't have been nearly so scarring for me if it hadn't broken so many web conventions and standards, like you don't mess with an html element's ID and that you allow more than one form element on a page.

5. Oh, now MVC is the hit again? (Anyone remembers Smalltalk?) How about Web Software Client Factory? You get MVC and ASP.NET server controls. Anyway, the challenge is not ASP.NET nor MVC nor... you name it. The difficulty is that we have to deal with HTML, DHTML, XHTML, WAP, JScript, VBScript etc. and none of the browsers are really compatible. And to be honest: That's all crap - nothing is state of the art. (At least the days of VHS video are over!

;-) After how many years?)

My proposed solution: Get rid of all the old crippled standards, throw away all browsers and start from fresh and do itright! - Unlikely? - Yes! - So I guess we have to stick with the idea that developing for the web will never be easy. Sorry guys! I say pick the right tool - sometimes ASP.NET, sometimes MVC extensions, sometimes Web Client Factory, Rails or whatever -for the task at hand. MVC is not a silver bullet...

From Sola Noah

1. The ASP.NET MVC Framework is essentially the Microsoft's attempt to create an ASP.NET programming environment centered around the MVC pattern. For the time being (nobody can reasonably foresee future evolutions), the MVC Framework should be considered an alternative to Web Forms. To some extent, the MVC Framework and Web Forms have in common more or less what cars and motorcycles share. Both can take you somewhere else, but with different speed, comfort, sense of freedom, size of the trunk.

The MVC Framework doesn't support classic postbacks and viewstate and doesn't consider any URL as the endpoint to a physical server file to parse and compile to a class. In ASP.NET, you have a 1:1 correspondence between a URL and a resource. The only exception to this rule is when you use completely custom HTTP handlers bound to a particular path.

I wonder what's the quickest and most effective way to explain the MVC Framework to seasoned ASP.NET developers. It's like having a central HTTP handler that captures all requests to resources identified with a new extension. This HTTP handler analyzes the syntax of the URL and maps it to a special server component known as the controller. The controller supports a number of predefined actions. The requested action is somehow codified in the URL according to an application-specific syntax. The central HTTP handler invokes the action on the controller and the controller will process the request up to generating the response in whatever response format you need. The response is generated through a view component.

What here I called the "central HTTP handler" plays the same role that was of the System.Web.UI.Page class in classic ASP.NET. The Page is the handler responsible for any .aspxrequest and generates the markup using the code-behind class and serves it back using postbacks. In the MVC Framework, this pattern - hard-coded in the ASP.NET runtime and not subject to change until the whole ASP.NET platform is rewritten - is simply implemented using an alternative HTTP handler and an alternative model based on REST and MVC.