I am wondering what the rationale was to not support postbacks in the MVC Framework?

One of the most common ways I've seen MVC implemented in ASP.NET was to create a Controller.aspx base page, or something similar, that routed the request to the appropriate page or controls, etc.  I believe there are numerous web articles out there descibing this approach and I know all of them support using the built-in controls, postbacks, data-binding, view state, etc.  I recently worked on a huge project developing a content management system for a multi-national company's business operations that was based on MVC with custom URL routing, etc. and had no problem supporting these things.

It seems to me that this framework has eliminated 90% of what ASP.NET is all about: server controls, page lifecycle, postbacks, view state and so on.  Wasn't it possible to develop a framework that extended the current functionality rather than replace and remove it???  What about all the time, experience and code put into DataGrid's, GridView's, FormView's, third-party control suites, etc.?  None of them can be used with this framework.

Please, someone help me understand so I can see the value of this framework cuz from where I stand, it looks like it has taken development back to traditional ASP with a better engine underneath.  Why take a step backwards?

 

You're right. Quite a few features from ASP.NET are not present in ASP.NET MVC. There are reasons for this. Simplicity and testability are the two that you may have read. Many developers thought that the Web Forms model just didn't work the way they wanted it to. First, it is extremely difficult to test using tools. Secondly, many developers believed the abstraction that is the Web Forms model was more complicated than the item (HTTP) it abstracts. Why should a page have a life-cycle that's so complex?

MVC isn't just about web forms vs. non web forms. It's not about clean URLs. It's certinatly not about the max amount of features. It represents a different way of thinking when developing web applications. It's much more than copying your page_load routing to your controller action.

Sure, they could have implemented all of those features in MVC, but many of those features are reasons why developers dislike WebForms in the first place. ViewState, by itself, is the most obscure and least understood part of WebForms. 

With ASP.NET MVC, you are not tied down to anything. You are not tied down to the view engine. You are not tied down to any controls. You are not even tied down to the web server. If you want to run your controllers via the console and test them, go right ahead. Don't like the view engine? Use another one. Brail, and NHaml are out there, just to name a few.

Reasons for MVC:

- It's clean.
- It's easily testable (eh, almost).
- Integration with IoC containers
- True Separation of Concerns.

If it's not for you, then it's not for you. WebForms isn't going anywhere.  

I really didnt like WebForms, and didnt use them once for a full scale commercial app. Just not how I like writing my web applications.

I have already done far more with the new Mvc framework than I ever did with WebForms.

It is all a matter of preference. Sounds like you should just ignore Mvc and carry on with WebForms.

It's a matter of preference really, neither is necessarily better than the other. A lot of developers get put off the Webforms model because it an effort to make things easier, and probably more consistent with developing a Winforms applications, ie button clicks, data binding etc, it broke the web model. Unfortunately people confuse MS MVC with Classic ASP because it is possible to use the inline code in the html like what was done with Classic ASP. But there is a lot more to it than this. You could use a totally different rendering engine if you wish. Two things l like most are 1st, separation of concerns is much easier, no more business logic in the user interface. 2nd, development of ajax apps with jquery finally feels natural rather than kludgy like it does with Webforms. And MS Ajax and Webforms never really worked for me, it always just felt heavy and cumbersome when I can do the same with with jQuery and a few extensions with no effort at all.

Doing things this way makes formal unit testing much much easier.  It may not sound like much but in large applications it's nice to be able to know exactly what's broken without having to dig for it. More over, I've personally found that I dont really like webforms as a programming model.  It does make the easy things easy, but sometimes fails to make the hard things possible.  As people said before this isnt going to replace webforms so much as supplement it.  If you want your controls & datagrids and viewstate and all that, you can still have it.  However if your of the opinion that all that stuff is just usless baggage which gets in the way of what your really want to do, then you dont need to deal with it in mvc. 

Well then, this really isn't asp.net any more. asp.net has been dumped and replaced with a Ruby On Rails clone!

 That is quite an extraordinary turn around.

Well that's not quite true. ASP.NET is way more than the Page/Control class. We're still making use of the core of ASP.NET, Http Modules, Http Handlers, Http Intrinsic classes.

Heck, we're still technically using WebForms for our default view engine (though in a more templatey way than a webformy way if that makes any sense).

So this is definitely ASP.NET. It's just not WebForms with its page lifecycle, viewstate, etc... ASP.NET at its core is a series of HttpHandlers and HttpModules. We're not the first to build an alternative to WebForms using the existing extensibility points. Monorail is one good example.

Secondly, many developers believed the abstraction that is the Web Forms model was more complicated than the item (HTTP) it abstracts. Why should a page have a life-cycle that's so complex?

 I don't think the web forms model was about reducing complexity. It was about automating persisting state across page requests. Remove web forms and that problem still remains. Everyone will now start rolling their own solution to the problem or just do it manually - field by field - like one would in asp classic or php.

Why don't the team just come up with a better way of doing this? It ought to be a bit simpler given that controls are no longer concerned with handling post back events. Using the MVC pattern has nothing to do with any of this. Its the stateless nature of http again.

I like the new approach, and it's the only reason I have any interest in developing pages in ASP.NET now.

And "support post-backs" is a really poor description, as you'll still do a postback , you just need to figure out what you want to do in your controller now, and change the view depending on it
it's still extremely easy since the View Pages support the <asp:container>.

And hey, you may need to use a proper javascript library, or write your own javascript now, but it's really NOT that difficult.
The new approach is how we done it in JSP and PHP (and how people do it in Ruby/Python/Classical-ASP as well, but I don't work with those).

The web is stateless, you can't change that. And ASP.NET shouldn't attempt to do so.

        "What about all the time, experience and code put into DataGrid's, GridView's, FormView's, third-party control suites, etc.?  None of them can be used with this framework."

You're saying you can't use a Table in the .NET MVC? And if you want dynamical controls, have a look at Ext2Js javascript framework, it's superiour to anything you ever could hand write in WebForms anyway. 

Thanks for giving us an alternative to web forms. I can't tell you how muchI am happy that viewstate is not an option in our framework. I can't count how many hours we have spent tracking down viewstate issues. Http is stateless, as it should be and there are multiple ways of "Storing" this kind of application state and most of them don't require a complicated mechanism for it. If you need viewstate for some reason, by all means use web forms. This is just an alternative and that is really nice to have. Please don't make viewstate an option MS. =)

As ShaneBauer pointed out ASP.Net MVC is not a replacement for WebForms its only an alternative.... just another option in ASP.Net Development.... Options are a good thing!!!  And most importantly its a MSFT supported framework. For those of us who have ever been employed by companies where that is a requirement.... having a Supported proper MVC framework is a good thing

Why not have the option to have controls that persist their state across post backs with the MVC pattern?

WhatThe12:

Why not have the option to have controls that persist their state across post backs with the MVC pattern?

you can do this manualy using session, application or profile variables

if you really like viewstate that much you can create your own implementation using a Dictionary<string, Object> and serializing it to a Base64 string and store it in a hidden field on your page.

this is very simple and would allow you to hae view state in the pages you want without having the whole post back mechanism

Yes but the point is that I don't want to have to do it manually. And when I pick up someone else's work, I don't want to have to work out their scheme that they've come up with for manually doing it either.

 If you don't like viewstate or controls automatically loading their state from the forms collection and the feature was there, then it would be even more simple if you just didn't use it or turned it off.

 I'm mean seriously, are you guys really up for having to assign to every text field in your form whenever a user posts back? I'm still waiting for someone to tell me that I've gotten it wrong and that in fact this does still happen automatically.

 

you can do this manualy using session, application or profile variables

 Yeah, nice encapsulation there.

WhatThe12:

Yes but the point is that I don't want to have to do it manually. And when I pick up someone else's work, I don't want to have to work out their scheme that they've come up with for manually doing it either.

Part of the point of MVC is to move to a more Convention over Configuration style.  MVC makes things easy, so long as you give things sensable names and have reasonable object layouts and such. So yes you run the risk of inheriting bad code but at the same time the framework makes it much easier to do things the right way.

 If you don't like viewstate or controls automatically loading their state from the forms collection and the feature was there, then it would be even more simple if you just didn't use it or turned it off.
 I'm mean seriously, are you guys really up for having to assign to every text field in your form whenever a user posts back? I'm still waiting for someone to tell me that I've gotten it wrong and that in fact this does still happen automatically.
 

Well here's how the flow goes:
1) You get your instance's id in action's parameter list.
2) You load your model from the database
3) You call BindingHelperExtensions.UpdateFrom(instance, Request.Form);
    -- so long as you named your form fields sane things like say the property names this will just work.
4) save your instance
5) call render view

 

you can do this manualy using session, application or profile variables

 Yeah, nice encapsulation there.