The trick with MVC is to realize that it's not some immutable magic spell, it gives results by enforcing a separation of concerns: data-modeling (and its manip

The trick with MVC is to realize that it's not some immutable magic spell, it gives results by enforcing a separation of concerns: data-modeling (and its manipulation and constraints) in the model, control-flow (and selecting and ordering the data to be presented) in the controller, and rendering it a certain way in the view. If you, as you suggest, have the view (essentially a glorified HTML template) request the data it needs (e.g. from multiple sources), then your data-selection and visual-presentation become tightly coupled. (The point of a view is that you can have multiple views of the same data). If the original view is handling things like data-selection and complex control flow, then when you want to create an alternate presentation of the same data, you'll end up copy-and-pasting code (c.f. "Don't Repeat Yourself"). So the best solution is to get a really good feel for separation of concerns, code-non-duplication, etc., and then organize your code accordingly. When using MVC, use every bit of it to keep your code simple and decoupled; if you just slap code into units called "models", "views", and "controllers" wherever you like, then you will receive NO BENEFIT (or negative benefit!) from using MVC. But, used properly, it can be a powerful tool.