TomB:
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/the-m-in-mvc-why-models-are-misunderstood-and-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.
Genuine request here… perhaps you could start with the code from the “From Flat PHP to Symfony2” article I linked to above, just before the article adds “a Touch of Symfony2,” and show additional step-by-step refactoring. Show a situation where you lose flexibility or repeat logic, and how you would fix that problem.