Magento Architecture

Magento's architecture does follows the well known MVC architecture but it actually does have some of its own additions which do help large scale web developments. Like we all know MVCs (Model, View and Controller) architecture is where you have a set of modules which comes with Models, Views and Controllers to split up your codes and make code management easier and simpler. In the conventional MVC, one would request the controller for a service and the controller would use models to get processed data and put forward the data to the view to give user the response and take another request which would be carried out in the same fashion. The conventional MVC works as illustrated below. Magento's architecture has added a lot more sub blocks to the above MVC architecture in order to handle bigger e-commerce system which can handle multiple sites / stores from the same back-end. Magento Architecture Views itself is broken into 3 parts, the model into 2 and you have controllers and helpers where helpers are module specific. If you are thinking that why helpers are module specific then you should know that Magento helpers and in fact all the models and controllers extends Magento core controllers, models and helpers so the common features are there in the super class whereas you can also add module specific features which you need not share to make big helper classes. To start off lets see the image below. We can see that Views have been split into three parts. The templates are the plainly html codes usually saved as phtmls with php tags to prints data and do some basic loops and some javascript calls like our usual view would look like. Next comes blocks which is a new concept to MVC. Blocks are simply used to lower the burden on central controller and make different views in a module more independent. This is important these days and any websites these days stands on a number of different blocks and some blocks may be AJAX loaded and provide different services. Therefore, Views have their own controllers to ask or request processed data from Models and provide graphical 'view' through templates. Blocks holds all the data and functions that can be called from the view template and Block can have nested blocks. Therefore, our website will have a root block, a header block, a navigation block and contents and footer block therefore they can be nested like that. Now, we might wonder what is the role of the central controller if every view comes with their own controller which can interact with models and helpers. That is where layout comes into play actually. In most of the definitions I read previously they say that in order to say which blocks goes with which template and in order to define which block is nested in which we need the layout. This is true but there is a little bit more to it. Layouts can only be called by a central controller name, therefore the central controller has the layout which defines the sub controllers (blocks) and the templates it contains. The central controller along with the helper provide service to the overall block set while the individual blocks provide service in email. Layout therefore simply provides a way to tell which is the super block and which are nested and how they are nested. Finally, Models contains Models ofcourse and collections. Models works as a service it provides functionalities for various business calculations and data processing, whereas, the collection is used to provide functions to retrieve the Data.