views:

934

answers:

4

I know what MVC is and I work in webforms but I don't know how MVC will be that much different. I guess the code behind model will be different. So will it be like webforms minus the code behind and instead having it in a controller?

I see there are other related posts but I don't they address this.

+2  A: 

The video tutorials here help describe the differences.

Quintin Robinson
+9  A: 

For starters, MVC does not use the <asp:control> controls, in preference for good old standard <input>'s and the like. Thus, you don't attach "events" to a control that get executed in a code-behind like you would in ASP. It relies on the standard http POST to do that.

It does not use the viewstate object.

It allows for more intelligent url mapping, though now that the Routing namespace has been spun off, I wonder if it can be used for WebForms?

It is much easier to automate testing of web parts.

It allows for much easier separation of UI logic from the "backend" components.

swilliams
Great info thanks
Brian G
asp.net 4.0 now allows routing. Personally, I handled this with my HttpModule but, now it's built in.
bbqchickenrobot
+1  A: 

MVC from a Web Forms perspective is more like minus the Postback than minus the code behind. So, that means the features of the controls that use postback will be rendered useless. You can still have logic in your code-behind.

Greg Ogle
+1  A: 

There is so much that can be said about your question.

MVC allows for clean separation of concerns, testability, and test driven development (TDD). It supports clean RESTful URLs and is very extensible... meaning you could swap out of the viewing engine, the routing mechanism, and many other things that you might not like out of the box.

For additional information I would suggest reading Dino Esposito's blog post entitled An Architectural View of the ASP.NET MVC Framework. Inside this post he compares many differences between the classic code behind approach with MVC.

Elijah Manor