MVC philosophy applied to webforms.

Question

I'm pretty new to programming in general (really started only 2 1/2 years ago) and I'm trying to decide what the best way is to approach a web app I'm making at work. A senior developer at work is encouraging me to get into MVC and after a good 24 hours of pouring over blogs, source code and other material on the subject I'm beginning to understand why I'd want to use it.

At the same time though, our company's existing apps are written as WebForms so I don't want to do something as drastic as using the actual ASP.NET MVC framework to make my app(would it really be THAT drastic though?).

What I'd really like to know is whether or not it would be practical or even possible to do WebForms but still follow the MVC philosophy of separation of concerns. Will I really just be adding an unnecessary layer to an already complicated .aspx + codebehind page?

Everyone in the blogosphere seems to think that they MUST use some kind of framework if they want to do MVC. What in WebForms is stopping them from just doing it themselves?

Answer 1

If a senior in your team is encouraging you to look into MVC for your app and you think it's a good move then go for it (if this app is stand-alone especially).

You can also look into the MVVM pattern. This is what many have done with WebForms and it is very similar to the MVC pattern. By applying the MVVM pattern to WebForms you would be showing how one can still use WebForms but get much of the goodness that is in the MVC pattern with ASP.Net MVC. It would be a nice way to show other devs in the team what can be done to make WebForms more SOC and testable without abandoning WebForms outright.

Here's a few more links on MVVM:

http://weblogs.asp.net/craigshoemaker/archive/2009/11/03/vm-workshop-model-view-viewmodel-mvvm-and-the-presentation-model-pattern-in-5-ui-platforms.aspx

http://russelleast.wordpress.com/2008/08/09/overview-of-the-modelview-viewmodel-mvvm-pattern-and-data-binding/

MVVM is also very popular in Silverlight apps....

There is also the MVP pattern as well. Here's an open source implementation for WebForms. This particular implementation is used by DotNetNuke 5.3.

A bit more explanation from MS on MVP and .Net

Either one of these is a great choice if you want to gain more control of your code but still have the WebForms features you enjoy and/or want to continue to have for any reason such as what it sounds like in your case of a lot of legacy code using it.

Answer 2

Yes, each version of MVC is even more drastically different from web forms than the previous one.

If you really don't want to use actual MVC, check out MVP (Model - View - Presenter) pattern.

Answer 3

IMHO, I think you should just make the move to MVC.

Here are a few reasons that I am making the transition:

• I like to be able to control my HTML output. [There are certain web controls that render different tags based on the browser. Additionally, it is nice to have control of the Client ID.]
• I like to be able to manage the state of my aplications. [As opposed to having WebForms try to manage it for me, passing larger chunks of data around than are strictly necessary.]
• I prefer to work in a test driven manner and I've found that I can get better test coverage with MVC.
• I've found that libraries like JQuery work incredibly well with MVC; I've found that making UI elements that were a pain in WebForms have become trivial in MVC.

So, getting back to your question... can you build WebForms apps that utilize many of the lessons of MVC. Sure, and if you are going to build WebForms apps I'd recommend it as a good practice. Can you apply frameworks to make it more like MVC. Sure, but why would you want to when you can just use MVC?