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

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 2

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 3

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 4

WebForms is a great framework, but it does requires for you to dig in and understand it. And yes, you should still be an expert in HTML and JavaScript. Every complaint that I ever hear about WebForms comes from someone who didn't take time to understand WebForms. Here are my answers to a few of them.

ViewState is Evil and will slow down the page

This reminds me of the programmers who made everything a global variable. You can certainly do it, but you SHOULD NOT! It's the same with WebForms and ViewState. Don't use ViewState unless you need to, and then only sparingly. There is nothing wrong in adding 1000 characters of view state to the html, if it will bring better user experience and/or speed up development time. You can experience the same problem in MVC by littering the page with hundreds of hidden input controls, and yes I've seen it. And by the way, ViewState is not "magical" it simply stores some data in a single input control and also encrypts it for good measure.

WebForms generates "ugly" html and is littered with long ids

Well, first of all, nobody actually looks at generated hmtl (did you look at google.com for example, it's a mess?!). Second, if you really care about generating specific html, it takes less than an hour to create your own re-usable component or control, with html of your choosing. Or you can take existing control, override rendering and use that control instead. Once again, you have to know where to go and how to do it, but once you know, it will be a great productivity boost without any sacrifices. Long ids are automatically generated to ensure uniqueness across the page. If you ever get a chance to develop a complex MVC view, you'll notice that you will inventing your own long id pattern, so that you can parse the form fields correctly on posting.

WebForms disallows multiple forms per page

I've been developing for 10 years and only once did I need multiple forms. And then I figured out that I didn't. You do have to understand HTTP requests and responses and how to achieve them with WebForms, but if you do, you'll never need multiple forms, nor will you ever think about "forms" at all.

WebForms pages are not testable

Absolutely not true. Even if you don't like MVP (which I don't), there are other techniques to test anything you want to test. It is true that if you just use pages in WebForms as is and put all logic in code-behid, it's probably not going to be testable and it's not a good idea. However, just like in MVC or Windows Forms applications, you can and you should, at least for complex views, create intermediary layers such as views and controllers. I prefer encapsulating functionality into user controls which implement an interface or inherit a base class. Then the page on which user controls reside on acts like a "master controller". Individual views, or user controls in this case, can be tested because they all implemement an interface or base class.

JavaScript is hard to do in WebForms

JavaScript is actually easier to implement in WebForms than in MVC. You sure have more options! But once again, you have to know WebForms well in order to realise this. In WebForms you can "inject" javacript with reusable components and controls. Or you can use it just like in MVC or plain HTML after changing a setting on the page to keep ASP implementing id naming scheme.

Having said all this, what does WebForms have to offer that MVC does not? Encapsulation and reusability of presentation components is by far the biggest, in my opinion. For complex views, I develop individual components (server or user controls) and than a custom controller or presentation factory weaves all of them into place. Additionally, design-time html is far cleaner in WebForms than in MVC, making design and styling a lot easier for properly trained graphic designers. It's cleaner because there is no programming code in design-time html, only markup (I don't use data binding expressions). And of course prototyping is much much easier in WebForms. For prototypes I will normally ignore all of the best practices and resort to wizards and ugly code-behind code that hits the database directly.

I could go on, but the main point I'd like to make is that WebForms and MVC are very different patterns and require different sets of knowledge and mindset to deliver great solutions. Both require as much of Web/HTTP/CSS knowledge as you can get. If I had to make one recommendation, generally, but not always, for high-traffic public website (such as blog) I may lean towards MVC. For complex web application, either internal/Intranet or membership external/Internet application, I would lean towards WebForms.

Answer 5

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 6

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).

Answer 7

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 8

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 9

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.