We all know how to get the rows (records) we need from Mysql, read the data, and then store and retrieve some changes. It's obvious and straightforward, and there's no beating around the bush behind the process. However, when we use object-oriented programming (OOP) to manage the data in our database, this process needs to be greatly improved. This article will give a brief description of how to design an object-oriented approach to manage database records. All the internal logical relationships in your data will be encapsulated into a very organized record object, which can provide a specialized (specific) validation code system, transformation and data processing. With the release of Zend Engine 2 and PHP 5, PHP developers will have more powerful object-oriented tools to assist their work, which will make this process (object-oriented database management) more attractive.


Listed below are some of the advantages of using objects to describe your database:


Accessor methods will enable you to read properties Complete control over the fetching and writing process
Every record and attribute (operation) at each level has a confirmation process
Intelligent acquisition of objects from the relational table
Reusable logical methods mean All data interactions must go through the same basic code (codebase), which will make maintenance easier
The code is simple because the internal logic of different records is already included in their respective classes. , instead of cumbersome library (lib) files
When manually writing code and SQL query statements, there will be fewer opportunities for errors


Accessor methods

The access method is to assign values ??to the variables of the instance through the class. For example, I have a class called User and an instance $username. I will write such access methods (functions). User->username() and User->setUsername() are used to return and give Instance assignment.



class User {
var $username;

function username() {
return $this->username ;
}

function setUsername($newUsername) {
$this->username = $newUsername;
}
}
?>




There are good reasons for writing "special code" like this.It will give developers more flexibility from the tedious work of changing classes because the process will not require additional PHP code that uses classes. Let's take a look at the more complete trusted User class below.


The variable $username will no longer exist, and everything will be integrated into the array $_data
If username is empty, the username() function will provide a default (default ) value to it
The setUsername() process will confirm whether the username conforms to the standard format (such as word length, etc.) before accepting the value.

class User {
var $ _data = array(); // associative array containing all the attributes for the User

function username() {
return !empty($this->_data['username']) ? $this ->_data['username'] : '(no name!)';
}

function setUsername($newUsername) {
if ($this->validateUsername($newUsername) ) {
$this->_data['username'] = $newUsername;
}
}

function validateUsername(&$someName) {
if (strlen($ someName) > 12) {
throw new Exception('Your username is too long'); // PHP5 only
}
return true;
}
}
?> ;



Obviously, this is very helpful for us to control the data of the access object. If a programmer is already accessing username information directly, the above code changes will break his code. However we can use the accessor methods (of the class), as commented in the code above, to add validation functionality without changing anything else. Note that the username verification code (which cannot exceed 12 bytes in the example) is independent of the setUsername() method. The process from validation to storage to database is a breeze. Moreover, this is a very good rule of thumb. The less a method or class needs to do, the greater the chance it will be reused. This is more obvious when you start writing a subclass, if you need a subclass, and you want to skip (ignore) some special details in the parent class method (behavior), if the method (for this detail) is small And it's delicate, (modifying it) is just a momentary process, and if this method is very bloated and serves multiple purposes, you may end up frustrated by copying a lot of code in the subclass.

For example, if Admin is a subclass of User class. We may have different, relatively harsh password verification methods for Adamin users. It's better to go over the validation method of the parent class and the entire setUsername() method (overridden in the child class).

More about Accessors
Here are some other examples to illustrate how to use Accessors more effectively. Many times we may need to calculate results instead of simply returning static data in an array. Another useful thing accessors can do is update values ??in the cache. When all changes (all operations on data) go through the setX() method, that's when we reset the value in the cache based on X.

So our class hierarchy becomes clearer:

The processing of the internal variable $_data is replaced by the protected private methods _getData() and _setData()
This type of method is transferred to an abstract super class called Record, which is of course a subclass of the User class
This Record class controls all access arrays$ The details of _data, calling validation methods before the content is modified, and sending notifications of changes to Records, as well as to the central ObjectStore instance.

class User extends Record {

// --- OMITTED CODE --- //

/**
* Do not show the actual password for the user, only some asterixes with the same strlen as the password value.
*/
function password() {
$passLength = strlen($this->_getData('password'));
return str_repeat('*', $passLength);
}
/**
* Setting the user password is not affected.
*/
function setPassword($newPassword) {
$this->_setData('password', $newPassword);
}

/**
* fullName is a derived attribute from firstName and lastName
* and does not need to be stored as a variable.
* It is therefore read-only, and has no 'setFullname()' accessor method.
*/
function fullName() {
return $this->firstName() . " " . $this->lastName();
}

/**
* Spending limit returns the currency value of the user's spending limit.
* This value is stored as an INT in the database, eliminating the need
* for more expensive DECIMAL or DOUBLE column types.
*/
function spendingLimit() {
return $this->_getData('spendingLimit') / 100;
}

/**
* The set accessor multiplies the currency value by 100, so it can be stored in the database again
* as an INT value.
*/
function setSpendingLimit($newSpendLimit) {
$this->_setData('spendingLimit', $newSpendLimit * 100);
}

/**
* The validateSpendingLimit is not called in this class, but is called automatically by the _setData() method
* in the Record superclass, which in turn is called by the setSpendingLimit() method.
*/
function validateSpendingLimit(&$someLimit) {
if (is_numeric($someLimit) AND $someLimit >= 0) {
return true;
} else {
throw new Exception("Spending limit must be a non-negative integer"); //PHP5 only
}
}
}

/**
* Record is the superclass for all database objects.
*/
abstract class Record {
var $_data = array();
var $_modifiedKeys = array(); // keeps track of which fields have changed since record was created/fetched

/**
* Returns an element from the $_data associative array.
*/
function _getData($attributeName) {
return $this->_data[$attributeName];
}

/**
* If the supplied value passes validation, this
* sets the value in the $_data associative array.
*/
function _setData($attributeName, $value) {
if ($this->validateAttribute($attributeName, $value)) {
if ($value != $this->_data[$attributeName]) {
$this->_data[$attributeName] = $value;
$this->_modifiedKeys[] = $attributeName;
$this->didChange();
} else {
// the new value is identical to the current one
// no change necessary
}
}
}

/**
* For an attribute named "foo", this looks for a method named "validateFoo()"
* and calls it if it exists. Otherwise this returns true (meaning validation passed).
*/
function validateAttribute($attributeName, &$value) {
$methodName = 'validate' . $attributeName;
if (method_exists($this, $methodName)) {
return $this->$methodName($value);
} else {
return true;
}
}

function didChange() {
// notify the objectStore that this record changed
}
}
?>



現(xiàn)在我們擁有了一個抽象的超級類（Record）,我們可以將User類里面大量的代碼轉(zhuǎn)移出來，而讓這個User的子類來關注User的特殊項目如存取和驗證方法。你可能已經(jīng)注意到在我們的這個紀錄類（Record class）沒有任何的SQL代碼。這并不是疏忽或者遺漏！對象存儲類（ObjectStore class）（隱藏在第二部分）將負責所有和數(shù)據(jù)庫的交互，還有我們的超級類Record的實例化。這樣使我們的Record類更加瘦小而又有效率，而這對于評價我們處理大量對象的效率的時候是個重要因素。