How is ENFORCED the separation of concerns in ASP.NET MVC?

Question

I have been studying, playing with and working with ASP.NET MVC since Preview 1 in 2007 (december). I have been a fan of it since 2008 and I support it all the way.

However I keep hearing and reading "ASP.NET MVC enforces a strict separation of concerns", including reading it in Professional ASP.NET MVC 1.0 by Rob Conery, Scott Hanselman, Phil Haack and Scott Guthrie.

What I don't understand is the enforcement. What if I define my controller with actions with nothing but

return View();

and in the view (aspx view engine) I do everything? (data fetching, business logic, decision making, rendering etc.)

How does it (ASP.NET MVC) ENFORCE me to separate the concerns?

I think this is a blatant overstatement and it should read "suggests a separation of concerns".

Can you convince me it enforces?

Answer 1

I don't think it enforces it, so they probably mispoke. Like you said, "suggests" or "promotes" is a better word.

Answer 2

The primary thing is that it start off on the right foot - i.e. a separate controller and view. If you choose to do something crazy, nobody will stop you. Except hopefully peer reviews. And common sense.

But contrast to webforms, where you have to try very hard not to mix the concerns.

Answer 3

Sure, you can do everything in the view. You'd just be a terrible programmer, and wouldn't be following the MVC pattern at all.

I'm also pretty sure there are some things you cannot do in the view at all, only in the controller. I may have my .Net and Rails confused, though.

Answer 4

What mechanism would you suggest for "enforcement" of the kind you want? Should the framework issue warnings when the cyclomatic complexity of View code exceeds some threshold? Should the framework run something like lint on your source and slap you on the wrist when you do un-MVC things (whatever those are)?

More to the point, what would be the benefit of all that finger-wagging? Aren't we trying to write applications that please our users?