asp.net mvc vs client-heavy webforms

When recently designing a medium to large scale web app, I decided to go with a client-heavy imp开发者_JAVA百科lementation of webforms rather than asp.net MVC for the UI layer.

The reason being that with webforms it is easy to quickly knock up screens and glue together a web app (I use Telerik's radcontrols extensively as they have a rich client model). I find that the earlier I get a prototype UI infront of a client, the quicker they can look at it and evolve it into what they really want.

When I say client-heavy webforms, I mostly bind data client-side and then use web services to handle events from the client - the web services interact with my business layer and deal in JSON. The advantage comes when, say, one UI event requires that many controls be updated - I can then fall back on the asp.net page cycle and fire off a partial-postback having wrapped the various controls in update panels.

The way I see it, I can have my cake and I can eat it! I can use lightning-fast JSON web services for performance critical areas of my app but I can revert to the postback/partial postback model for complex UI areas. All in all, less development time and performant where it matters.

So finally, a question!

I'm not trying to resist MVC just simply asking is it better than what I'm doing above and if so, why?

Your reasons for using web forms are valid: rapid prototyping to get mock UI in front of a client. The other reason would be the huge number of vendors who offer server controls to dump into web forms pages.

I personally think MVC has a bit of a learning curve for those who are used to having a drag-n-drop designer rather than editing the HTML by hand. That said, once you get past it I don't believe you'd ever use web forms again. There are a lot of controls popping up that work very nicely with MVC. Telerik's MVC Extensions are just one example, that happens to be open source as well.

You fallback to page postback in certain cases, this means that you are actually maintaining two different models. One at the client side and one at the server side. In case of the post back, you make the changes at the server side and now you need to find a way to communicate that changes to the client side. I don't know how you are doing this but this is not entirely scalable because every change has to be synced in between client side and server side both. In MVC we take care of this using server side View Models which are automatically taken care at the client side by the framework. (On top we use client-side binding libraries like Knockoutjs, which are far more easier to use with MVC than webforms)

Secondly you don't get the routing advantages too in webforms. So you routes still look those ugly Mysite.com/mypage.aspx.

I have a real estate app here: www.homevana.com. This is a web forms app but I bet you wouldn't know it. For the requirements of this project, a client heavy app that still utilized web forms at times when there was large complex forms to complete to gather data about the home for sale was the sweet spot. So most .aspx pages on the Homevana app have no code behind but when there are forms with complex validation I used .aspx pages with server controls and Peter Blum's validation suite: http://www.peterblum.com/Home.aspx (all complex client side validation of course) to rapidly get that aspect of the job done.

The FriendlyUrl package that you can install via nuget: http://www.hanselman.com/blog/IntroducingASPNETFriendlyUrlsCleanerURLsEasierRoutingAndMobileViewsForASPNETWebForms.aspx gets rid of that "ugly" .aspx extension easily though you can do it with one IIS7 regex url routing rule too.

It is all about the right tool for the job. MVC is awesome and I have many other projects where I use MVC but it isn't always the best tool for the requirements of the project.