By Prem Tiwari. Updated on
Although Model-View-Controller (MVC) is known by nearly every Web developer, how to properly use MVC in real application development still eludes many people. The central idea behind MVC is code reusability and separation of concerns. In this section, we describe some general guidelines on how to better follow MVC when developing a Yii application.
To better explain these guidelines, we assume a Web application consists of several sub-applications, such as
1) front end: a public-facing website for normal end users
2) back end: a website that exposes administrative functionality for managing the application. This is usually restricted to administrative staff
3) console: an application consisting of console commands to be run in a terminal window or as scheduled jobs to support the whole application
4) Web API: providing interfaces to third parties for integrating with the application.
The sub-applications may be implemented in terms of modules, or as a Yii application that shares some code with other sub-applications.
Models represent the underlying data structure of a Web application. Models are often shared among different sub-applications of a Web application. For example, a LoginForm model may be used by both the front end and the back end of an application; a News model may be used by the console commands, Web APIs, and the front/back end of an application. Therefore, models
1) should contain properties to represent specific data
2) should contain business logic (e.g. validation rules) to ensure the represented data fulfills the design requirement.
3) may contain code for manipulating data. For example, a
SearchForm model, besides representing the search input data, may contain a
search method to implement the actual search.
So, if we were to employ this strategy in our above example, we would add a News model in the front end application that contains only the getLatestNews method, and we would add another News model in the back end application, which contains only the getDeletedNews method.
In general, models should not contain logic that deals directly with end users. More specifically, models
should not use
$_POST, or other similar variables that are directly tied to the end-user request. Remember that a model may be used by a totally different sub-application (e.g. unit test, Web API) that may not use these variables to represent user requests. These variables pertaining to the user request should be handled by the Controller.
should avoid embedding HTML or other presentational code. Because presentational code varies according to end user requirements (e.g. front end and back end may show the detail of a news in completely different formats), it is better taken care of by views.
Views are responsible for presenting models in the format that end users desire. In general, views
should mainly contain presentational code, such as HTML, and simple PHP code to traverse, format and render data;
should avoid containing code that performs explicit DB queries. Such code is better placed in models.
should avoid direct access to
$_POST, or other similar variables that represent the end user request. This is the controller’s job. The view should be focused on the display and layout of the data provided to it by the controller and/or model, but not attempting to access request variables or the database directly.
may access properties and methods of controllers and models directly. However, this should be done only for the purpose of presentation.
Controllers are the glue that binds models, views and other components together into a runnable application. Controllers are responsible for dealing directly with end user requests. Therefore, controllers
1) May access
$_POST and other PHP variables that represent user requests.
2) May create model instances and manage their life cycles. For example, in a typical model update action, the controller may first create the model instance; then populate the model with the user input from
$_POST; after saving the model successfully, the controller may redirect the user browser to the model detail page. Note that the actual implementation of saving a model should be located in the model instead of the controller.
3) Should avoid containing embedded SQL statements, which are better kept in models.
4) Should avoid containing any HTML or any other presentational markup. This is better kept in views.
In a well-designed MVC application, controllers are often very thin, containing probably only a few dozen lines of code; while models are very fat, containing most of the code responsible for representing and manipulating the data. This is because the data structure and business logic represented by models is typically very specific to the particular application, and needs to be heavily customized to meet the specific application requirements; while controller logic often follows a similar pattern across applications and therefore may well be simplified by the underlying framework or the base classes.
Sharing is caring!