Benefits of using objects in Databases

We all know how to obtain the required rows (Records) from Mysql, read the data, and then access some changes. Obviously, it is also very direct, and there is nothing behind this process. However, when we use Object-Oriented Programming (OOP) to manage data in our database, this process needs to be greatly improved. This article will give a simple description of how to design an object-oriented approach to manage database records. All internal logical relationships in your data will be encapsulated into a very organized record object, which can provide a dedicated (specific) validation code system, conversion, and data processing. With the release of Zend Engine2 and PHP5, PHP developers will have more powerful object-oriented tools to assist in their work, which will make this process (in the face of Object-based database governance) more attractive.

The following lists some useful aspects of using objects to describe your database:
The access method (Accessor methods) gives you full control over the Read and Write processes of attributes.
Each record and attribute (operation) at each level has a validation process.
Intelligently retrieve objects from Relational Tables
The repeated logic method means that all data interaction is performed through the same basic code (codebase), which makes maintenance easier.
The code is simple, because the internal logic of different records is already included in their own classes, rather than the tedious Library (lib) file.
When you manually write code and SQL query statements, fewer errors may occur.

Accessor methods)

The access method is to assign values to the variables of an instance through a class. For example, I have a class named User and an instance $ username. I will write such an access method (function), User-> username () and User-> setUsername () are used to return and assign values to instances.

<? Php
Class User {
Var $ username;

Function username (){
Return $ this-> username;
}

Function setUsername ($ newUsername ){
$ This-> username = $ newUsername;
}
}
?>

There is a good reason for us to write such "extraordinary code ". It will make the developer more flexible to change the tedious work of the class, because this process will not require other php code using the class. Let's take a look at the more comprehensive and trustworthy User class below.
The variable $ username will no longer exist, and everything will be integrated into the array $ _ data.
If username is null, the username () function will provide a default value to it.
The setUsername () process will confirm whether the username complies with the standard format (such as the font length) before accepting the value)

<? Php
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 for accessing objects. If a programmer has directly accessed the username information, the above Code changes will destroy his code. However, we can use the (class) access method, as noted in the code above, to add a verification function without changing anything else. The code that focuses on username verification (in this example, it cannot exceed 12 bytes) is independent of the setUsername () method. The process from verification to storage to database is easy. In addition, this is a very good experience-based method. The less a method or class needs to be done, the more chance it will be used repeatedly. This is more obvious when you start to write a subclass. If you need a subclass and want to skip (ignore) some extraordinary details in the parent class method (behavior, if (for this details) the method is very small and fine, (to modify it) is just a flash, and if this method is very bloated, for a variety of purposes, you may end up with a lot of code in the replication subclass.

For example, Admin is a subclass of the User class. We may have different and more demanding password verification methods for adamin users. It is best to overwrite the verification method of the parent class and the entire setUsername () method (in the subclass ).