Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Apr 27, 2008 10:16 AM by kirchi
Mar 17, 2008 06:29 PM|LINK
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?
Mar 17, 2008 07:01 PM|LINK
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.
Mar 17, 2008 10:47 PM|LINK
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.
Mar 18, 2008 12:33 AM|LINK
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.
Mar 18, 2008 01:19 AM|LINK
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.
Mar 24, 2008 02:06 AM|LINK
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.
Mar 24, 2008 02:33 AM|LINK
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.
Mar 24, 2008 10:33 AM|LINK
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
Mar 24, 2008 01:23 PM|LINK
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>.
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."
Mar 24, 2008 03:09 PM|LINK
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. =)