Someone said Magento was not strictly MVC structured. I am intended to accept this point. But MVC does give people an easy way to understand how system works. So if I regard Magento as an MVC system, which part of MVC do Magento blocks fall into?
I used to think blocks were Views because they were tied with templates. As time goes, now I think blocks are Models because blocks implement a lot of business logic as Magento model classes. Today I have another reason to support blocks are Models:
When a frontend_model is initialised for a Sytem Configuration field or an EAV attribute field, it is actually a block class.
I put block as V because it is often tied with a phtml. And when it is not, it still generates html codes. But the line is often blur. In SalesRule and Rule modules, the main rendering engine to output the conditions in html is actually in models. So I can argue that Model in Magento is V.
Dealing with output is necessary but not sufficient condition of being a View. What View is dealing with is the part that users “often” want to customise. The arguable thing is how often is “often”.
Take Magento navigation (generating top menu) for example, because it recursively goes down the category tree, it is not easy to be template driven. So Magento put all the html output in a block class. Seeing that, you can say Magento block is View. However, in my opinion, Magento should not put the html output in this block class, because:
Take adminhtml form elements for another example, they look gorgeous and consistent. Magento has made most web elements I can ever think of ready to use. I hardly need customise one for my own purposes. Magento allows me to “define” the elements but not encourages me to “customise” a new one (although customisation is still possible). If we all the time had to “customise” something, we were likely lose consistency. It falls into my logic that these elements are Model instead of View although they output standard html code.