About ASP.NET MVC Model and that WebForms

I don't have real understanding of the MVC model or Architecture yet but what I read and see is that it separated the 'Concerns' that is the presentation UI and logical code, right? But I k开发者_JAVA技巧now that WebForms Architecture also has a code behind model which then separates the code and UI.

Is there something else also in MVC which further separates the stuff around?

The main difference between MVC and WebForms is that in WebForms it is the view that receives the request (/foo.aspx), while in MVC it is the controller (/controller) which will manipulate the model and choose the appropriate view to render. Another important difference is that all the HTTP Context stack (Request, Response, Session, ...) has been abstracted behind abstract classes and interfaces in ASP.NET MVC which allows for better separation of concerns and unit testability in isolation. You also have far more control over the generated markup in ASP.NET MVC in contrast to WebForms where the markup is essentially generated by server side controls.

Code-behind is specifically what makes UI tightly coupled to business logic in WebForms -- the code-behind is part of the UI.

Using controllers instead of code-behind is one of the primary ways in which MVC decouples these concerns.

The easiest way to think about this is that the .aspx and code behind are essentially two different views of the same component, the UI. It's completely possible to use code behinds with MVC (if you're using the webforms view engine), but both the view and the code behind are considered part of the UI. The controller is a seperate entity, as is the model.

Code-behind is specifically what makes UI tightly coupled to business logic in WebForms -- the code-behind is part of the UI.

Only if you choose to let it.

Business logic will not be coupled to UI if you choose to have seperate business layer/tier and implment an appropriote UI layer pattern such as MVP/MVC/MVVM. Id argue a n-layer design with an MVP pattern in webforms can offer even greater seperation of concerns than asp.net MVC but requires alot more upfront design.

Asp.Net MVC forces better seperation out of the box. Its baked into it. This is good for developers who might not know any better. With webforms it is completly up to the architect/developer to select the level of sepearion required, a double edged sword because if you're experienced with the platform can do some great stuff, but if your new to it or coming from a classic asp style of development you may make a mess of it without some guidance.

Biggest plus I see for asp.net MVC over webforms isnt soc, or testability (as they can be acheived in webforms) it's the ability have better control over markup (if you need it) and the more web centric focus (again, if thats what you need).