Traditional ASP .NET Web Forms vs MVC

As someone with some winforms and client applications experience - is it worth going back and learning the way traditional ASP .NET pages work, or is it okay with moving straight into ASP .NET MVC?

I'm kind of looking for pitfalls or traps in my knowledge of general C#, that I won't know from the screencast series and things on the ASP .NET site.

Solution 1:

Here is the great thing about MVC. It works closer to the base of the framework than normal ASP.NET Web Forms. So by using MVC and understanding it, you will have a better understanding of how WebForms work. The problem with WebForms is there is a lot of magic and about 6 years of trying to make the Web work like Windows Forms, so you have the control tree hierarchy and everything translated to the Web. With MVC you get the core with out the WinForm influence.

So start with MVC, and you will easily be able to move in to WebForms if needed.

Solution 2:

I agree with Nick: MVC is much closer to the real web paradigm and by using it you'll be confronted with how your website really works. WebForms astracts most of these things away from you and, coming from a PHP background, I found it really anti-intuitive.

I suggest you directly jump to MVC and skip WebForms. As said, you'll be able to get back to it if needed.

Solution 3:

ASP.Net Webforms is a completely different abstraction over the base framework than ASP.NET MVC. With MVC you've got more control over what happens under the covers than with ASP.NET Webforms.

In my opinion learning different ways to do things will usually make you a better programmer but in this case there might be better things to learn.

Solution 4:

ASP.NET MVC is for developers who desire to decouple the client code from the server code. I have wanted to write JavaScript, XHTML, CSS clients that can move from server to server (without regard to server technology). Clients are time-consuming to fit and finish so you would want to use them (and sub-components) for as many servers as possible. Also this decoupling allows your server to support any client technology that supports HTTP and angle-brackets (and/or JSON) like WPF/Silverlight. Without ASP.NET MVC you were forced into a hostile relationship with the entire ASP.NET team---but Scott Guthrie is a cool dude and brings MVC to the table after years of his predecessors (and perhaps Scott himself) almost totally focused on getting Windows Forms programmers to write web applications.

Before ASP.NET MVC, I built ASP.NET applications largely based on ASHX files---HTTP handlers. I can assure you that no "real" Microsoft shop would encourage this behavior. It is easier from a (wise) management perspective to dictate that all your developers use the vendor-recommended way of using the vendor's tools. So IT shops that are one or two years behind will require you to know the pre-MVC way of doing things. This also comes in handy when you have a "legacy" system to maintain.

But, for the green field, it's MVC all the way!