MVC Implementation

As a beginner like me you would find some of the terms in Zend Framework frightening but here I am going to use the simplest explanations that helped my understanding.

MVC (Model, View & Controller) is a “design pattern” (another word you I would explain later) which allows application business logic to be separated from the user interface and data models, such that they can be manipulated independent of each other.

In the past when developing a PHP application, the typical approach is to embed PHP code into one or more HTML documents using special delimiters. This made it easy to construct dynamic Web pages containing programming constructs like variables and function’s calls; simply alter the values of the variables embedded within the HTML code, and the content displayed on the page changes appropriately.

The approach made editing codes cumbersome and the MVC design pattern was preferred. Zend Framework 2 design and structure follows this concept separating the view script from the model and controller script so that each can be edited independently.

Model

Every application is driven by data, whether it’s something as simple as a username and password or as complex as a multicurrency shopping cart. In the MVC pattern, this “data layer” is represented by one or more models, which provide functions to retrieve, save, delete, and otherwise manipulate application data. All the database activities are managed from the model classes.

View

If models are concerned solely with accessing and manipulating the application’s raw data, views are concerned with how this data is presented to the user. Views can simply be thought of as the “user interface layer,” responsible for displaying data but not capable of directly accessing or manipulating it.

Views can also receive input from the user, but their responsibility is again limited to the appearance and behavior of the input form; they are not concerned with processing, sanitizing, or validating the input data.

Controller

Controllers are the link between models and views. They make changes to application data using models, and then call views to display the results to the user.

Controllers can thus be thought of as the “processing layer,” responsible for responding to user actions, triggering changes in application state, and displaying the new state to the user. In our next we would look at the module’s system and create our first module. I guess it is time to get into some coding.