We all know how to get the rows (records) We need from MySQL, read the data, and then access some changes. It's obvious and straightforward, and there's no roundabout way behind the process. However, when we use object-oriented programming (OOP) to govern the data in our database, this process needs to be greatly improved. This article will make a simple description of how to design an object-facing way to govern the database's records. All the internal logic in your data will be encapsulated into a very organized record object that provides a dedicated (specific) validation code system, transformation, and data processing. With the release of Zend Engine2 and PHP5, PHP developers will have more powerful tools to support their work, which will make the process (in the face of object governance databases) more appealing.
Here are some useful aspects of using objects to describe your database:
The Access Method (Accessor methods) will give you complete control over the read and write process of the property
Each level has a confirmation process for each record and attribute (the operation)
Getting objects intelligently from a relational table
The repeated use of logical methods means that all data interactions pass through the same underlying code (codebase), which makes maintenance easier
The code is simple because the internal logic of the different records is already contained within the class, not the cumbersome library (Lib) file
Fewer opportunities for errors when writing code and SQL query statements manually
Access method (Accessor methods)
Access is done by assigning a value to a variable in the class to the instance (instance). An example, I have a class called User, and there is an instance of $username, I will write such access methods (functions), User->username () and User->setusername () to return and assign values to the instance.
Class User {
var $username;
function username () {
return $this->username;
}
function Setusername ($newUsername) {
$this->username = $newUsername;
}
}
?>
There are good reasons for us to write such "extraordinary code". It will give developers more flexibility in changing the tedious work of the class, because this process will not require other PHP code to use the class. Let's take a look at the more complete and trustworthy user class below.
Variable $username will no longer exist, everything is 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 that the username conforms to the standard format (such as word length) 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 has access to username information directly, the changes in the above code will break his code. However, we can use the (class) access method, just as commented in the code above, to add a validation function without changing anything else. The emphasis on username verification (in the case that no more than 12 bytes) code is independent of the Setusername () method. The process from validation to storage to the database is a breeze. Moreover, this is a very good experience-based approach, the less a method or a class needs to be done, the greater the chance of its reuse. This is even more noticeable when you start to write a subclass, and if you need a subclass, and you skip (ignore) Some of the extraordinary details of the parent method (behavior), if the method (for this detail) is small and fine, (modifying it) is just a momentary process, and if the method is bloated, for multiple purposes, You might end up in a lot of code in a copy subclass.
For example, if admin is a subclass of the user class. We may have different, relatively harsh password authentication methods for adamin users. It is best to cross the validation method of the parent class and the entire Setusername () method (overridden in a subclass).
http://www.bkjia.com/PHPjc/631386.html www.bkjia.com true http://www.bkjia.com/PHPjc/631386.html techarticle we all know how to get the rows (records) We need from MySQL, read the data, and then access some changes. Obviously also very direct, behind this process there is no roundabout ...
