Here is my personal understanding of the principles of MVC, without regard to any specific platform or implementation:
The model is an API to the domain of the application that is not coupled to anything else. It is suitable for use with a user interface, automation, or as a component of a larger model. If the application domain is about storing data, then the model will provide access to that data and enforce its validity. But the domain could also be something that is not stateful per se, like interfacing with hardware.
A view is an independent component of a user interface for the model, and is tightly coupled to it. It allows humans to interact with some part of the model in some way.
The controller organizes views into a complete end-user application by instantiating them and connecting them to models. It should be minimally coupled to the details of views and models, and is optionally composable.
People have been confused about MVC for a very long time. This article should have come out back in 2003.
Struts, Ruby-on-Rails and most (if not all) of the other server-side web frameworks have always been something very different from the original MVC implementation in Smalltalk, and in fact, most "MVC" implementations in GUI systems deviate in some major way from the original.
From my viewpoint, the "model" is less fundamental in "Server-side MVC" than the other components. The first step towards a framework is having a controller than can serve up different views in different situations: if your form doesn't validate, you can serve the form up again or you can serve a different page if it does... I remember the "bad old days" of cgi-script programming where the form and the form processor were in different scripts and you couldn't do server-side validation the right way.
Ruby has a particular strong role for the model, which has some advantages and some disadvantages.
Interesting point there. I haven't thought about it that way before, because intuitively the model appears to be the most important. And of course it is when you look at the application as a whole, but from a http perspective, the controller is the pivotal point. If you begin to think about the model as an external service for the web application, clearly the controller becomes the most important element.
The model is an API to the domain of the application that is not coupled to anything else. It is suitable for use with a user interface, automation, or as a component of a larger model. If the application domain is about storing data, then the model will provide access to that data and enforce its validity. But the domain could also be something that is not stateful per se, like interfacing with hardware.
A view is an independent component of a user interface for the model, and is tightly coupled to it. It allows humans to interact with some part of the model in some way.
The controller organizes views into a complete end-user application by instantiating them and connecting them to models. It should be minimally coupled to the details of views and models, and is optionally composable.