Quote Originally Posted by Jeff Mott View Post
I think most of your questions can be answered with this explanation:

The definitions of MVC were written with desktop applications in mind, and it doesn't translate perfectly to stateless, server-side web applications. MVC controllers are supposed to handle user input -- which could be mouse clicks, key presses, touches, gestures, device orientation, etc -- and translate that input into commands for the view and the model. But in server-side web applications, there's only one input: the HTTP request. And MVC views are supposed to be able to react to user input, as well as to changes in the model. But in server-side web applications, there won't be any new user input for the view to react to, nor will there be any changes to the model that would require the view to update itself.

Because of these differences, MVC was a bit bastαrdized in its adaptation to the web. Views in web applications are little more than templates, and the templates don't access the model directly. Instead they are fed data by the controller, which acts as a mediator between the model and the view. It turns out there's another design pattern that more accurately reflects the way server-side web applications work, called Presentation–abstraction–control.

With that explanation out of the way, I'll add my two cents... that even though what most developers and frameworks have been using all this time isn't MVC in its purest sense, I think the architecture that web applications have settled on is a good one. For example, I think it's a good thing that the views/templates don't access the model directly. It lets them stay small in scope, ignorant of -- and independent of -- the larger application.

at the expense of flexibility and the addition of repeated binding logic. The *******ised approach tightly couples the controller to the template and in some cases, the model, essentially locking everything together and making it inflexible. Keep in mind, it's the misunderstanding of the MVC model in the first place that caused this mess ( http://blog.astrumfutura.com/2008/12...unappreciated/ ) In any non-trivial application (and if you're using MVC your application will fall into "non-trivial") MVC models are not domain models. They're designed to exist as a bridge between the domain and the GUI. As such, it makes perfect sense for Views to know of them.

As I've said before, the reason that we call PAC "MVC" in the web world is that people were trying to implement MVC. The architecture was stumbled upon by people accidentally missing the point of MVC. The original MVC architecture was created by academics who thought very carefully about what they were trying to achieve and it offers many advantages over the pseudo-MVC most frameworks offer. And the web actually lets you create a purer implementation of the architecture because you don't have to worry about refreshing views to account for state changes in the model.