Using Smart Architecture in PHP_PHP Tutorial

I've wanted to write this article for a long time, but never had the time. This is not intended to tell you how to do it, I hope it can shed some light on how to develop a good, scalable web application.

I have been engaged in development for 2-3 years. Looking back at the programs I first made, I really don’t believe that I wrote them myself. Now my web development skills have been greatly improved, such as sourceForge (http://sourceforge.net/) is one of my more mature works. The code is divided into various classes and functions. The structure of the database is also very clear. Different parts of the site are independent from other parts.

But this site is not perfect. If I have to write it again, I will make the HTML layer and database layer more clearly distinguished through objects or function libraries.

I have found that many managers like to express their ideas in the form of charts, and I will also provide one here. The idea of ​​this system is to separate your logic from the surface layer, which means that anything complex will be pushed down to the "API/data access layer".

For security check, update and other codes, you'd better not put them in the HTML layer. You should put these theoretical codes in the API layer. The HTML layer will just make simple function calls and return arrays, objects, or my favorite, database result sets.

In this diagram, the HTML interface either directly calls the API layer, or calls an HTML tool library (such as generating pop-up windows, etc.), and those libraries can call the database through a database abstraction layer (so you don’t have to bind fixed on some kind of database).

Basic points
For a smart system, there are the following basic points:
1. Database independent
2. Presentation layer independent
3. Easy to modify
4. Object-oriented or at least split into function library calls
These are what I think of. In addition to the above mentioned, there must be other points, you can put them forward in the forum.

Let us discuss the above points in detail:

1. Database independence
When you are designing, you may not know how much burden your site will have. Therefore, you should remember that it cannot be bound to a lightweight database, such as MS Access or others. Therefore, you should consider scalability. If you change the database, you do not need to make too many changes, or even make any changes. This is ideal.

When using PHP, the function calls for various databases are different, and you need to code differently for the database you use. To change this situation, you can use a database abstraction layer such as PHPLib or a library developed by others.
2. Presentation layer independence
If you want to develop a really large and complex application, you have to start thinking about database interface issues, so that you can save a lot of copy and paste work. For example, you need to make your site WAP-enabled so that mobile phone users can access it. If your application is well designed, you only need to write a lightweight WAP presentation layer to call all your database access objects. However, if your application system is not well designed, you may need to rewrite it, so that You need to maintain an HTML version and a WAP version at the same time.

For example, when developing the SourceForge site, we had a large number of users submitting their bugs and tasks. Initially we designed it to be all done through the web interface. Later, under pressure from some people, we decided to use XML interface to display the database. We successfully separated the core logic of the site from the presentation layer. Currently, bug tracking and other tools on SourceForge use two different libraries - the HTML library class and the database class. The data class is responsible for checking whether the input value is valid and handling security detection, while the presentation layer just returns true or false based on success/failure. To simplify, this example will not be based on a perfect object model while I have to explain the base classes and how other objects extend these base classes. But I think this example can help you establish some concepts.

Example of HTML class

//Connect to database
require ("database.php");

//Commonly used HTML header/footer
require ("html.php");

//Data access library class
require ("bug_data.php");

echo site_header("Page Title");

echo "
Updating A Bug


";

if (bug_data_update($field1,$field2,$field3)) {

echo "

Update Failed!
";

} else {

echo "
Updated Bug Successfully
";
/ /show global error string
echo $feedback;
}

echo site_footer();

?>

Example Data Access Lib

/**
* Controls a bug in the update database
* Checks data validity and security, and returns true when successful,
* returns false when failed
*
*
*/

function bug_data_update ($field1,$field2,$field3) {
//Global string, return error
global $feedback;

//$field1 and $field2 are required
if (!$field1 || !$field2) {
$feedback="Field 1 And Field 2 Are Required";
return false;
}

//Confirm that the user has the right to update
if (!user_isadmin()) {
$feedback="You Must Be An Admin To Update a Bug";
return false;
}

//The bug can now be updated

$result=db_query("UPDATE bug ".
"SET field2='$field2',".
"field3='$field3' ".
"WHERE id='$field1'");

//Now check whether your statement is executed successfully
if (!$result) {
//update failed
return false;
} else {
return true;
}
}

?>
3. Easy to modify
Of course you won't use absolute URLs throughout the entire application, but I would go one step further. The choice of colors, element names, fonts, and other possible options should not be absolute at best, they should be in Set it in a configuration file and include that file on every page. The style of the site should also be self-contained - so you don't have to copy and paste it on every page, I usually put the HTML in a function that can then be called when needed.

Database passwords, database connections, etc. are also placed in the database abstraction layer.

4. Object Oriented/Functional
We can split process processing into different function calls. Each call does one thing, and sometimes you just need to call other functions and return the results.

A good example is checking in every page whether a user is logged in. If you don't use objects or functions, when your authentication system changes, you have to make changes on each page, rather than just changing a function call in the library. Before you write a piece of code, think about it. If it is going to be used more than once in the site, you will have to move it to a library. Anything to add?
I'm sure there are some things I haven't thought of, so please give me your thoughts. In particular, you have written a large and complex application. I would like to know what kind of system you would build and what changes you would make if you had to write it again.