MVC, such a big deal?
This is one of the posts where I should be going to bed rather than starting this but I just won't sleep if I don't post it. I was going over the comments in Ayende's post on Castle Igloo and noticed someone had posted this.
"Communication between a view and its associated controller is straightforward because View and Controller are specifically designed to work together. Models, on the other hand, communicate in a more subtle manner."
"Unlike the model, which may be loosely connected to multiple MVC triads, Each view is associated with a unique controller and vice versa. Instance variables in each maintain this tight coupling."
-- Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC) http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html
In fact if you read Martin Fowlers essay on GUI Architecturer it captions a MVC UML diagram with
Essential dependencies between model, view, and controller. (I call this essential because in fact the view and controller do link to each other directly, but developers mostly don't use this fact.)
So the view and controller are tightly bounded and the coupling of the two in accordance with the pattern is ok. In that context webforms meets the defination of view (aspx) and controller (code behind) . The couple is one of web coupling, it's a web framework after all but you can't easily mock events or context data and although the couple is valid it quickly stands in the way of testability.
MVC frameworks that adapt to webforms extend the controller and view to reduce the couple so tightly. The view can register to the controller with out a strict contract, in this case what occurs is that the codebehind and view unify as one view and the controller a new class. By making the controller more like a class we can inject events and mocks to it with out a web context and increase testability in doing so. We do stretch things a bit here in a pattern layers sense as the view is now taking on events and data population passing to the code behind which in turn goes to the controller class so the code behind becomes a bit of a piggy in the middle between the pattern layers. When we consider MonoRail it has true degrees of seperation between pattern layers and testability to boot, best of both worlds.
As with any pattern is using what fits for you and your project, they are not set in stone and you can adapt where you see fit.