[eluser]mradlmaier[/eluser]
Hi all,
I haven`t read through all the post about this, but in think one aspect to keep in mind is the deeper reasons why we use MVC in practical terms. Then it becomes a bit more clear what to put where, why and when. We don`t use it, just because it is cool to do so. We use because it, because we want to achieve minimal coupling of parts of our application.
For examples, the real advantage of separating the model (your application data) is, that instead of a relational database you one day could decide to store your application`s data in a flat file. So if you have correctly separated your controller from your model, you should be able to do this without changing anything in the controller. There should be a clearly defined interface between controller and model. The same goes for the view and the controller.
So, the way i decide which goes where, is simply to try to imagine if things still work, if the model or the view or the controller is exchanged by a different implementation. If i can do that without breaking the whole thing, then everything should be in the right place / makes sense.
In the end, a developers job is not to 'correctly' design an application, but to deliver an application with minimal effort, while maintaining a high degree of agility, if costumers requirements change.
So any design pattern should not be seen as a 'religion', but just a tool to get the job done.
Michael