This may be an old post, but it was quite an interesting read on MVC, which I had only recently started reading about. After a thorough read through all the comments, I've come to a rather simple, but viable conclusion about how the MVC can be interpreted safely. I will however 100% agree that the concept is open to interpretation. So here's my view:
The Model can be viewed as your database itself, with the information in it, along with the server-side code whose sole job is to retrieve, update and alter subsets of that stored information. This could include also and low-level business logic that would be commonly or regularly performed on the data before being used.
The Controller would essentially be the middle man between the Model and the View, whose job is to respond to user interaction, decide what the interaction was, decide how to handle it, and what to do with the information/interaction retrieved from the user. The Controller would take that information and often contact the Model to either update, or retrieve a subset of data based on the user's interaction. The Model would respond with the appropriate subset or possibly no subset if it was an action query of some sort, and return control to the Controller. The Controller would then take that subset of data, if available, and direct the user to the appropriate View, where the data can be presented to the user.
I stumbled upon a set of classes I used in part to complete a school project from which you instantiate a few basic PHP Objects: The Database Object, The Session Object, and the Form Object. Also, there was a controller.php page that intercepted all form submissions and utilized any Controller Objects as needed. The Controller objects would in turn communicate with the Database Object.
A user would be presented with a Registration Form. Upon submission, as with every form submission, control is directed to controller.php.
controller.php makes use of the Session Object's "Register" Method. This method would validate the user's input, build the Form Object with Input Values and Errors. If no errors were found, control is directed to the appropriate Method in the Database Object.
The Database Object would update the user table with the new values, and return control to the Session Object, giving it a response of Success or Failure.
If the update to the Database was successful, the Controller would decide which View to present to the user, along with a "Registration Successful" message. In this case, control would likely be directed back to Registration page.
The Registration page would take the Success message it received from the Controller and display it to the user, and most likely hide the registration form. From here, the process starts over based on the users next interaction.
So as a conclusion, the MVC is no more than a documented structure on which most good programmers already develop applications. So the separation concept behind it is not an unfamiliar one at all. It is a great concept and can be effectively implemented in MOST applications, but not all. The advantage, as I see it, is the ability to present a developer with a Programming Paradigm to keep in mind as he/she develops their application. If the developer follows a similar sort of structured separation, they will inevitably end up with more easily maintainable and scalable code. That being said, the programmer is not limited to this exact flavor of MVC, but rather can build his/her own conception of this sort of separation and as long as it results in organized, scalable and maintainable code, I'd say the odds are good of it representing a Valid form of MVC.
So if this thread is still even remotely alive, please let me know what you folks think of my interpretation. Keep in mind that I've only been programming for about a year if destructive criticism comes to mind - Zach