Wow. This is a really ugly workaround for a problem that began when you started using MVC. I would assume that any savings in db calls is completely wasted in processing overhead. Even more was wasted just coming up with this rigmarole. More reasons why MVC is bad juju.
With respect I think you have missed the point a little. The thing this idea solves is separating data-fetching optimisation from code layout. Regardless of whether you use MVC or entirely procedural code, it gets very hard to keep data access optimal when you have very complex and highly modular pages without introducing hacky globals or coupling unrelated parts of the code together (should be obvious why that's bad).
For any one page you may be able to change the structure so that it is more efficient without compromising the code too much but some of those modules will need to be reused in a completely different context on a different page.
I'm perhaps not explaining very well but this idea isn't solving deficiencies with MVC, it is solving a problem inherent in ANY attempt to modularise/re-use code. To gain the same data-access efficiency without MVC would leave your code unreadable not to mention un-maintanable with a complex site and high frequency changes.
Many sites simply don't need this so yes it would be overkill and of little benefit for them. I don't think the article was suggesting such a scheme would work well for everyone else. If you do have pages which legitimately need to make hundreds of queries/cache gets to resolve the data requirements though, techniques like this can help a lot.
Comments
Wow. This is a really ugly workaround for a problem that began when you started using MVC. I would assume that any savings in db calls is completely wasted in processing overhead. Even more was wasted just coming up with this rigmarole. More reasons why MVC is bad juju.
With respect I think you have missed the point a little. The thing this idea solves is separating data-fetching optimisation from code layout. Regardless of whether you use MVC or entirely procedural code, it gets very hard to keep data access optimal when you have very complex and highly modular pages without introducing hacky globals or coupling unrelated parts of the code together (should be obvious why that's bad).
For any one page you may be able to change the structure so that it is more efficient without compromising the code too much but some of those modules will need to be reused in a completely different context on a different page.
I'm perhaps not explaining very well but this idea isn't solving deficiencies with MVC, it is solving a problem inherent in ANY attempt to modularise/re-use code. To gain the same data-access efficiency without MVC would leave your code unreadable not to mention un-maintanable with a complex site and high frequency changes.
Many sites simply don't need this so yes it would be overkill and of little benefit for them. I don't think the article was suggesting such a scheme would work well for everyone else. If you do have pages which legitimately need to make hundreds of queries/cache gets to resolve the data requirements though, techniques like this can help a lot.