MVC versus WebForms

Question

It seems to me like there's a lot of sheeping going on, with everyone jumping on the MVC bandwagon. Almost everyone is declaring WebForms as evil and satan without much persuasion. Then they go on to say that Controls are evil and they shouldn't be in a Web app. How are you going to show anything without any controls?

I remember when WebForms first came out and everybody loved them. I guess in a few years, people will sheep on to the next thing and declare MVC evil because you had to actually create controls to use MVC and they'll say you have to develop an application and not worry about the controls.

The way I see it MVC can be achieved in WebForms by not including the RunAt in the Form tag. Then if you want to retrieve data, just use Ajax.

Can someone persuade me on why I should use MVC and not WebForms?

Answer 1

WebForms work fine and if you like them, continue to use them.

Three of the big advantages to MVC model as I see it are:

ViewState is gone, which could create a fairly sizable amount of traffic over the wire. URLs can be remapped to mean something as is all the rage now. Scaffolding. I don't know, personally I think this is satan and encourages terrible programming habits, but other seem to think its a beautiful idea.

It also encourages a a proper separation between business logic and presentation by enforcing the Model-View-Controller pattern, but good WebForm code can mostly do that as well.

So, really, if you are fine with the overhead of WebForms, and ok with ugly URLs and don't want scaffolding, stick with WebForms.

EDIT: Oh, I did miss one major advantage of "clean" urls. And MVC application is much friendlier for SEO. It also gives you fine control over HTML, but frankly, I don't consider that much of a step forward.

Answer 2

You shouldn't arbitrarily decide between one or the other; don't plump for the MVC framework just because it's the new kid on the block and everyone's singing its praises, especially not if you're comfortable with doing things using Web Forms. Practically every existing system is going to be using the older, more established technology, and there's nothing wrong with that.

While it's true that the MVC framework does allow for even easier separation of concerns (after all, that's what the MVC pattern is for), it also brings with it the responsibility of writing more HTML, and I think a slightly greater understanding of how the web works; not necessarily an unreasonable requirement, but you could argue it'll slightly slow you down the first few times you set about using it.

To be honest, I agree that Web Forms takes a lot of undeserved flack. Granted, there's a lot of magic going on in the background, and you get less control over some of the HTML output, but it's not exactly impossible to style with CSS (you end up using !important a lot, perhaps), and it's also not impossible to get some separation of concerns, even if it doesn't meet the purist's view of what that might be. You can still write pretty horrible code using the MVC framework. If you're looking to throw together something quickly, and you're good with Web Forms, then you're going to be able to achieve that very quickly, and it's nothing to be ashamed of, is it?

That's not to say, of course, that you should stick to your guns and ignore MVC either; it's a good framework (in fact, it's a very good framework) and it does confer several benefits which you might want to take advantage of in the long run. You also have to remember that it doesn't automatically nullify everything you learned about ASP.NET 2.0, either; a lot of the supporting architecture is embraced in the MVC framework, including things like the membership providers.

Answer 3

Not me. MVC is pretty cool in a resume, but for our customers (those who pay for our work), it's not a show stopper.

They usually want applications that are right, fast and secure. That's all. They will not want to change the third layer of the client part in three years ! In three years, they will change every thing or nothing at all.

Layers are fun to architect and to code, but they cost a lot to create and to maintain and they are not relevant to our customers. MVC is pretty cool but really useless and expensive.

Unless, of course, you are developping applications for 4 OS and 3 plateforms... But you will then be a minority.

:o)

Answer 4

In Webforms:

Both Viewstate and Postbacks have been made lot of problems and increased complexity of the web application development. Many web pages having hundreds of KB size of Viewstate that affected the performance of the applications sometime.

Developers do not have the control of the rendering HTML of web forms and Server controls that render html with mixed inline style and deprecated tags that does not follows standards.

The page life cycle of the Web Form is too complex and has the tightly coupling between all things in the ASP.net framework and a single class is used both to display output and handles user input.

Unit testing is almost an impossible task. Today unit testing is very important in modern software development especially when we following agile methodologies and practices. Since web is a stateless thing, Events, Postbacks and Viewstate are not a good way.

With asp.net MVC all these things are simplified

If these things don't apply to you and you enjoy using Webforms then stick with what you do best. Don't try to fix something thats not broken.

For more detail refer to : Shiju's blog of ASP.net MVC Vs ASP.net Web Form

Answer 5

I see the key advantages of MVC as:

• Much cleaner and simpler architecture. No more guessing which event you have handle to hook up your data correctly. No more having to insert a hook to "fix" a data binding problem because the framework doesn't do exactly what you want.
• The framework doesn't get your way as much.
• Decoupled architecture makes much more of the code more easily tested.
• More closely aligned with the architecture of the web. For people coming from a WebForms background this may not seem to be an advantage until you embrace it and design for it instead of trying to write WebForms-like applications in MVC. Fortunately, I had explored Ruby on Rails some before using ASP.NET MVC and had already started to write my WebForms apps in a more RESTful way.
• History/Ubiquity -- despite the fact that Microsoft is just rolling it out, MVC is a well-known and highly respected pattern. It's widely used for lots of web applications in many frameworks. Learning MVC will give you a leg up if you need to switch to a different technology where they are also doing MVC -- say RoR or Java/Struts.

The disadvantages:

• Microsoft's implementation is new and not as mature.
• Few third-party "controls"/plugins for round-trip use -- generic grids and such, though there are lots of plugins on the client-side via jQuery.
• Requires unlearning some paradigms from WebForms to effectively use it.
• The framework doesn't do as much heavy lifting for you; you'll have to learn some Javascript and write more client-side code because the framework won't inject it for you.

Answer 6

I think part of the problem, is that many people don't realise that MVC isn't an M$ invention, nor is it a replacement for webforms. Certainly, people like "new" things, and people like to throw buzzwords around, particularly to improve their resumes...

Finally .NET developers have some choice, and with that choice, they are being thrust some degree of responsibility for the decisions they make. I'm not surprised many webforms developers are nervous about this responsibility. It's not been there before. Ultimately, it can make you a better developer, or a worse one. It's now up to you.

People loved webforms, because it was better than ASP (Classic). And yes, in 5 - 10 years, I'm sure someone/group much smarter than I, will evolve a new paradigm/pattern.
Be careful with the sheep lable, as in a way, by holding onto a vendor specific pattern (webforms) you are potentially a bigger "sheep".
MVC is now across a variety of platforms, and means your potential to develop meaningful and stable solutions to problems can be dramatically increased. Or decreased. It's ultimately up to you. If you're not ready to go, then wait for ASP.NET MVC to mature. But don't close your mind to anything, particularly a pattern that is very very well established!

I recommend reading Rob Connery's extremely inflammatory blog. He certainly strummed my pain with his fingers! Then go and read RoR stuff, Cake, and Struts. All of these will start showing you the vision that the guys who brought MVC to .NET have (~ish) and hopefully will inspire you to see problems differently!

Answer 7

This is a stupid discussion - they are different, ASP.NET MVC and WebForms are different technologies! I'm using MVC for all new projects, but when I am faced with a need for RAD I use WinForms, because it is simple and there are a lot of controls already written by gurus.

Stop discussing this. Who wants to understand difference? Just try both technologies and you will understand by yourself.

Answer 8

There have been several, more detailed, answers here, so rather than repeat anything they have said I'll try to keep my answer a bit more succinct. You shouldn't, necessarily use MVC over webforms, just as you shouldn't use webforms over MVC - they are both tools and are more, or less, appropriate in different situations. I was first exposed to MVC quite a few years ago on J2EE, when .NET was first coming out (I'm not sure the ASP.NET MVC was available at that time). It gives a really nice, clean framework and gives more "web" applications (i.e. request/response), but you can also add in a lot more client-side functionality using AJAX - I have done some really funky things using AJAX on a php app I wrote a while ago and that is all usable under MVC.

There are some things that MVC does better and some things that webforms do better, but if you don't know both technologies you can't choose the best one for the current project you are doing, so please don't do yourself a disservice - go and learn MVC. Even if you never use it directly, it may still give you useful "theory" knowledge you can apply in other tools. I try to learn as many different things as I can, as the more strings to my bow I have, the less likely it is that I will not be able to solve a problem (for example, in that php app, I used php, hooked into a bit of ASP, and even had DOS and *NIX batch/script files performing certain functions - each tool had its place and was best suited to the job to which it was allocated).