MVC versus WebForms [closed]

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

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 3

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.