Zend Framework: A Beginner s Guide in C#

Reader Data Matrix ECC200 in C# Zend Framework: A Beginner s Guide

spl_autoload_register(array('Doctrine', 'autoload')); // create Doctrine manager $manager = Doctrine_Manager::getInstance(); // create database connection $conn = Doctrine_Manager::connection( 'mysql://square:square@localhost/square', 'doctrine'); // auto-generate models Doctrine::generateModelsFromDb('/tmp/models', array('doctrine'), array('classPrefix' => 'Square_Model_') ); >

This script sets up a connection to the database created in the previous section, and then uses the generateModelsFromDb() method to dynamically generate models corresponding to the tables in the database These models will be saved to the directory named in the first argument to the method Notice also that, in the array passed to the method as third argument, there s an option that tells Doctrine to prefix each model class name with a custom string This is useful to have the models conform to the Zend Framework s autoloading subsystem Execute this script at the command prompt using the PHP CLI, as follows:

If all goes well, Doctrine will write a set of models to the specified directory Take a look, and you should see something like Figure 4-4 These models should now be copied to the application directory To do this, change to $APP_ DIR and execute the following commands:

Figure 4-4

shell> mkdir library/Square/Model shell> cp /tmp/models/* library/Square/Model shell> cp /tmp/models/generated/* library/Square/Model

By default, the Doctrine model generator uses the model class name as the basis for the corresponding filename So, for example, a model class named Square_Model_Item will be saved to a filename Square_Model_Itemphp Unfortunately, this arrangement does not sit well with the Zend Framework s autoloader, which expects a class named Square_Model_Item to be saved as Square/Model/Itemphp To resolve this, it s necessary to manually rename each of

4:

the generated model class files, removing the prefix that was automatically added by Doctrine Here s an example:

At the end of the process, you should have a structure that looks like Figure 4-5

If you re using Doctrine v12, you can pass an additional 'classPrefixFiles' option to the generateModelsFromDb() method This specifies whether or not the class prefix should be added to the model filenames Setting this to 'false' reduces the work involved in getting Doctrine models integrated with your application, as it is no longer necessary to rename each model file to conform to Zend Framework conventions

Notice that Doctrine maps each table in the database to two model classes: a base class and a child class The base class extends the Doctrine_Record class, includes the table definition, and exposes (via inheritance) all the methods for common database operations The child class is a stub class derived from the base class, and it serves as a container for any custom methods that you might want to add to the model

Now, while Doctrine can produce models that correspond to individual tables and expose methods for common operations on those tables, it doesn t have the intelligence to automatically detect relationships between tables However, these relationships are often critically important in practical use, so it s up to the application developer to define these relationships by linking models together Doctrine makes it possible to replicate all the different types of relationships possible in an RDBMS one-to-one, one-to-many, manyto-many, and self-referencing using just two methods: hasOne() and hasMany() Both these methods take two arguments: the name of the other model to be used in the relationship, and an array of options specifying parameters for the relationship To ensure that these relationships are automatically loaded when the model is instantiated, they should be used within the model s setUp() method

Figure 4-5

(continued)

To understand how this works, flip back a few pages to Figure 4-3, which illustrates the relationships between the various database tables It should be clear from Figure 4-3 that there exists a 1:n relationship between the country, grade, and type master tables on the one hand, and the item table on the other This relationship makes use of the itemCountryID, item GradeID, and itemTypeID foreign key fields, and it can be expressed in Doctrine by adding the following code to the Item model class:

< php class Square_Model_Item extends Square_Model_BaseItem { public function setUp() { $this->hasOne('Square_Model_Grade', array( 'local' => 'GradeID', 'foreign' => 'GradeID' ) ); $this->hasOne('Square_Model_Country', array( 'local' => 'CountryID', 'foreign' => 'CountryID' ) ); $this->hasOne('Square_Model_Type', array( 'local' => 'TypeID', 'foreign' => 'TypeID' ) ); } }

Here, the setUp() method takes care of automatically defining the foreign key relationships between the Item model and the Country, Grade, and Item models This comes in handy when joining these tables together in a Doctrine query (as you ll shortly see)