I've heard the phrase "fat model, thin controller" and believe I understand it's implications. While working through the Zend Quickstart Guide I have come across the Table Data Gateway pattern.
It seems to me that this design pattern is advocating a fourth component to the MVC stack. It is moving away from a "Fat Model" to "thin model, thin controller and fat TableDataGateway". From my understanding of this design pattern, the Model becomes very little more than a storage mechanism for the data that the TableDataGateway stuffs into it.
I understand the advantages of the Table Data Gateway design pattern with abstracting our data source, my question isn't about the design pattern, but rather how it fits into the MVC stack.
P.S. I'm having a bit of a hard time getting my question into good words. If someone wants to edit this to make it clearer or make a suggestion I'm open!
The MVC schema could be updated as follow :
+------------+
| Controller |
+------------+
^ ^
| | +------------+ +-------------+
| |-------> | Model | <--> | Data access |
| | +------------+ +-------------+
| |
v v
+------------+
| View |
+------------+
The data access part is just an other level of abstraction (based on the Data Gateway design pattern, or any other pattern/technique) which is the specific part that talk to your persistent level (text files, database or any other) which can be easily replaced if you ever need to change your persistent level in your application (ie: going from MySQL to Oracle).
This way, the only part you have to rewrite is the data access level and the rest of the application is still working. The task of the model is now to format data in a way that can be used either by the controller or by the view.
This might not be the best or the most complete answer, but its at least a beginning.
