Agile Web Application Development with Yii1.1 and PHP5: For PHP developers who know object-oriented programming, this book is the fast track to learning the Yii framework. It takes a step-by-step approach to building a complete real-world application – teaching by practice rather than theory.

Typically in an MVC architecture, the model is responsible for maintaining state. Thus, it should encapsulate the business rules that apply to the data that defines this state. A model in Yii is any instance of the framework class CModel or its child class. A model class typically comprises data attributes that can have separate labels (something user-friendly for the purpose of display), and can be validated against a set of rules defined in the model. The data that makes up the attributes in the model class could come from a row of a database table or from the fields in a user input form.

Yii implements two kinds of models: The form model (CFormModel class) and the active record model (CActiveRecord class). They both extend from the same base class CModel. CFormModel represents a data model that collects inputs in HTML form. It encapsulates all the logic for form field validation and any other business logic that may need to be applied to the form field data. It can then store this data in memory, or with the help of an active record model, store data in a database.

Active Record (AR) is a design pattern used to abstract database access in an object-oriented fashion. Each AR object in Yii is an instance of CActiveRecord or its child class that wraps a single row in a database table or view, encapsulates all the logic and details around database access, and houses much of the business logic that is required to be applied to that data. The data field values for each column in the table row are represented as properties of the AR object. AR is described in more detail a little later.

Typically, the view is responsible for rendering the user interface, based on the data in the model. A view in Yii is a PHP script that contains user interface related elements, often built using HTML, but can also contain PHP statements. Usually any PHP statements within the view are very simple conditional or looping statements, or refer to other Yii UI-related elements such as HTML helper class methods or prebuilt widgets. More sophisticated logic should be separated from the view and placed appropriately in either the model (if dealing directly with the data), or in the controller for a more general business logic.

The controller is our main director of a routed request and is responsible for taking user input, interacting with the model, and instructing the view to update and display appropriately. A controller in Yii is an instance of CController or its child. When a controller runs, it performs the requested action, which then interacts with needed models and renders an appropriate view. An action, in its simplest form, is a controller class method whose name starts with the word action.

To help all of this make more sense, let's look at a fictitious example. Pretend we have used Yii to build ourselves a new blog site, yourblog.com. This site is similar to most typical blog sites out there. The home page displays a list of recently posted blog posts. The names of each of these blog postings are hyperlinks that take the user to the page that displays the full article. The next diagram illustrates how Yii handles an incoming request sent from clicking on one of these hypothetical blog post links.

The figure traces the request made from a user clicking on the following link: http://yourblog.com/post/show/id/99

First, the request is sent to the router. The router parses the request to decide where to send it. The structure of the URL is key to the decision the router will make. By default, Yii recognizes URLs with the following format: http://hostname/index.php?r=ControllerID/ActionID

The r querystring variable refers to the route that is analyzed by the Yii router. It will parse this route to determine the appropriate controller and action method to further handle the request. Now, you may have immediately noticed that the URL mentioned in the previous example does not follow this default format. It is a simple matter to configure the application to recognize the more search engine friendly format: http://hostname/ControllerID/ActionID

We will continue to use this simplified format for the purposes of this example. The ControllerID in the URL refers to the name of the controller. By default this is the first part of the controller class name, up to the word Controller. For example, if your controller class name is TestController, the ControllerID would be Test. Similarly, ActionID refers to the name of the action that is defined by the controller. If the action is a simple method defined within the controller, this will be whatever follows the word Action in the method name. For example, if your action method is named actionCreate() , the ActionID is Create.

Turning back to the example, the router will analyze the following URL, http://yourblog.com/post/show/id/99, and will take the first part of the URL path, post to be the ControllerID and the second part, show to be the ActionID. This will translate to routing the request to the actionShow() method within the PostController class. The last part of the URL (id/99) is a name/value querystring parameter that will be available to the method during processing. In this example, 99 represents the unique internal id for the selected blog post.

The actionShow() method handles requests for specific blog post entries. In this case, it uses the querystring variable, id to determine which specific post is being requested. It asks the model to retrieve information about blog post entry number 99. The model AR class interacts with the database to retrieve the requested data. After retrieving the data from the model, the controller class further prepares it for display by making it available to the view. The view then renders the needed HTML in a response back to the user's browser.

This MVC architecture allows us to separate the presentation from the model, and the controller from the view. This makes it easy for developers to change aspects of the application without affecting the User Interface (UI) and for UI designers to freely make changes without affecting the model or business logic. This separation also makes it very easy to provide multiple presentations of the same model code. For example, you could use the same model code that drives the HTML layout of yourblog.com to drive a Flash/Flex RIA presentation or a mobile application or web services, or a command-line interface. In the end, following this set conventions and separating the functionality will result in an application that is much easier to extend and maintain.

Yii does a lot more to help you enforce this separation than simply providing some naming conventions and suggestions for where your code should be placed in a folder structure. It helps to take care of all the lower-level glue code needed to stitch all the pieces together. This allows you to reap the benefits of a strict MVC designed application without having to spend all the time coding the details yourself. Let's take a look at some of these lower-level details.

As was previously mentioned, AR is a design pattern used to abstract database access in an object-oriented fashion. It maps tables to classes, rows to objects and columns to object attributes. In other words, each instance of an active record class represents a single row in a database table. However an AR class is more than just a set of attributes that map to columns in a database table; it also houses the needed business logic behavior to be applied to that data. The end result is a class that defines everything about how it should be written to and read from the database.

By relying on convention and sticking with reasonable defaults, Yii's implementation of AR will save the developer a ton of time normally spent in configuration or in writing tedious and repetitive SQL statements required to create, read, update and delete data. It also allows the developer to access data stored in the database in a much more object-oriented way. To illustrate this, here is some example code that uses AR to operate on a specific blog posting whose internal id, which is also used as the table's Primary Key, is 99. It first retrieves the posting by Primary Key, it then changes the title, and then updates the database to save the changes:

$post=Post::model()->findByPk(99);
$post->title='Some new title';
$post->save();

Active Record completely relieves us of the tedium of having to write any SQL or otherwise deal with the underlying database.