Active Records are objects that wrap a row in a database table or view, encapsulates the database access and adds domain logic on that data. The basics of an Active Record is a business object class, e.g., a Products class, that match very closely the record structure of an underlying database table. Each Active Record will be responsible for saving and loading data to and from the database.
Active Record is a good choice for domain logic that isn't too complex, such as creates, reads, updates, and deletes. Derivations and validations based on a single record work well in this structure. Active Record has the primary advantage of simplicity. It's easy to build Active Records, and they are easy to understand.
However, as your business logic grows in complexity, you'll soon want to use your object's direct relationships, collections, inheritance, and so forth. These don't map easily onto Active Record, and adding them piecemeal gets very messy. Another argument against Active Record is the fact that it couples the object design to the database design. This makes it more difficult to refactor as a project goes forward.
The alternative is to use a Data Mapper that separates the roles of the
business object and how these objects are stored.
Prado provides a complimentary choice between Active Record and
SqlMap Data Mapper.
A SqlMap Data Mapper can be used to load Active Record objects, in turn, these
Active Record objects can be used to update the database.
The "relationship" between Active Records and SqlMap is illustrated in the
following diagram. More details regarding the SqlMap Data Mapper can be found in
the SqlMap Manual.
alt="Active Records and SqlMap DataMapper" id="fig:diagram.png" class="figure"/>
The Active Record class has methods that do the following:
The Active Record implementation utilizes the Prado DAO classes for data access. The current Active Record implementation supports the following database.
Support for other databases can be provided when there are sufficient demand.
Let us
consider the following "users" table that contains two columns named "username" and "email",
where "username" is also the primary key.
Next we define our Active Record class that corresponds to the "users" table.
Each property of the UserRecord class must correspond to a column with the same name in the "users" table. The class constant TABLE is optional when the class name is the same as the table name in the database, otherwise TABLE must specify the table name that corresponds to your Active Record class.
Since TActiveRecord extends TComponent, setter and getter methods can be defined to allow control over how variables are set and returned. For example, adding a $level property to the UserRecord class:
The static method finder() returns an UserRecord instance that can be used to load records from the database. The loading of records using the finer methods is discuss a little later. The TActiveRecord::finder() static method takes the name of the current Active Record class as parameter.
A default database connection for Active Record can be set as follows.
See Establishing Database Connection for
futher details regarding creation of database connection in general.
The default database connection can also be configured using a <module>
tag in the application.xml
or config.xml as follows.
A ConnectionID property can be specified with value corresponding
to another TDataSourceConfig module configuration's ID value. This allows
the same database connection to be used in other modules such as SqlMap.
The TActiveRecord class provides many convenient methods to find
records from the database. The simplest is finding records by matching primary keys.
See the
Finds one record using only the primary key or composite primary keys.
Finds multiple records using a list of primary keys or composite primary keys.
The following are equivalent for scalar primary keys (primary key consisting of only one column/field).
Finds one single record that matches the criteria. The criteria can be a partial SQL string or a TActiveRecordCriteria object.
The TActiveRecordCriteria class has the following properties:
Same as find() but returns an array of objects.
Dynamic find method using parts of method name as search criteria. Method names starting with findBy return 1 record only. Method names starting with findAllBy return an array of records. The condition is taken as part of the method name after findBy or findAllBy. The following blocks of code are equivalent:
Finds records using full SQL, returns corresponding array of record objects.
Find the number of matchings records.
Add a new record using TActiveRecord is very simple, just create a new Active Record object and call the save() method. E.g.
To update a record in the database, just change one or more properties of
the Active Record object that has been loaded from the database and then
call the save() method.
Active Record objects have a simple life-cycle illustrated in the following diagram.
We see that new TActiveRecord objects are created by either using one of the find*() methods or using creating a new instance by using PHP's new keyword. Objects created by a find*() method starts with clean state. New instance of TActiveRecord created other than by a find*() method starts with new state. When ever you call the save() method on the TActiveRecord object, the object enters the clean state. Objects in the clean becomes dirty whenever one of more of its internal states are changed. Calling the delete() method on the object ends the object life-cycle, no futher actions can be performed on the object.
To delete an existing record that is already loaded, just call the delete() method. You can also delete records in the database by primary keys without loading any records using the deleteByPk() method. For example, to delete one or records with tables having a scalar primary key.
For composite primary keys (determined automatically from the table definitions):
To delete by a criteria, use deleteAll($criteria) and deleteBy*() with similar synatx to findAll($criteria) and findAllBy*() as described above.
All Active Record objects contains the property DbConnection
that can be used to obtain a transaction object.
The Prado Active Record implementation supports the foreign key mappings for database that supports foreign key contraints. For ActiveRecord relationships to function the underlying database must support foreign key constraints (e.g. MySQL with InnoDB).
In the following sections we shall consider the following table relationships between Teams, Players, Skills and Profiles.
The goal is to obtain object models that represents to some degree the entity relationships in the above figure.
There is a mismatch between relationships with objects and table relationships. First there's a difference in representation. Objects handle links by storing references that are held by the runtime memory-managed environment. Relational databases handle links by forming a key into another table. Second, objects can easily use collections to handle multiple references from a single field, while normalization forces all entity relation links to be single valued. This leads to reversals of the data structure between objects and tables. The approach taken in the Prado Active Record design is to use the table foreign key constraints to derive object relationships. This implies that the underlying database must support foreign key constraints.
The entity relationship between the Teams and Players table is what is known as an 1-M relationship. That is, one Team may contain 0 or more Players. In terms of object relationships, we say that the Team object has many Player objects. (Notice the reversal of the reversal of the direction of relationships between tables and objects.)
We model the Team object as the following Active Record classes.
The static $RELATIONS property of TeamRecord defines that the property $players has many PlayerRecords. Multiple relationships is permitted by defining each relationship with an entry in the $RELATIONS array where array key for the entry corresponds to the property name. In array(self::HAS_MANY, 'PlayerRecord'), the first element defines the relationship type, the valid types are self::HAS_MANY, self::HAS_ONE and self::BELONGS_TO. The second element is a string 'PlayerRecord' that corresponds to the class name of the PlayerRecord class.
The foreign key constraint of the Players table is used to determine the corresponding Teams table's corresponding key names. This is done automatically handled in Active Record by inspecting the Players and Teams table definitions.
The has many relationship is not fetched automatically when you use any of the Active Record finder methods. You will need to explicitly fetch the related objects as follows. In the code below, both lines are equivalent and the method names are case insensitive.
The method with_xxx() (where xxx is the relationship property name, in this case, players) fetchs the corresponding PlayerRecords using a second query (not by using a join). The with_xxx() accepts the same arguments as other finder methods of TActiveRecord, e.g. with_players('age < ?', 35).