I wanted to write this article a long time ago, but I never had time. I don't want to tell you how to do it here. I hope it can be used to discuss with you how to develop a good and scalable web application. I have been engaged in development for 2-3 years. looking back at the program I just started, I really don't believe it was my own. now my web development skills have been greatly improved, for example, sourceForge (sourceforge.net) was a long time ago when I wanted to write this article, but I never had time. I don't want to tell you how to do it here. I hope it can be used to discuss with you how to develop a good and scalable web application.
I have been engaged in development for 2-3 years. looking back at the program I just started, I really don't believe it was my own. now my web development skills have been greatly improved, for example, sourceForge (http://sourceforge.net/) is a more mature work of mine, the code is divided into various classes and functions. The database structure is also clear. Different parts of the site are independent from other parts.
However, this site is not perfect. If I have to write it again, I will split the HTML layer from the database layer by using objects or function libraries.
I found that many managers like to express their ideas in the form of charts. here I also provide one. The idea of this system is to separate your logic from the surface layer, which means that anything complicated will be put down on the "API/data access layer ".
For security check, update, and other code, you 'd better not put it in the HTML layer. you should put the theoretical code in the API layer. The HTML layer only calls simple functions and returns arrays, objects, or my favorite database result sets.
In this figure, the HTML interface either calls the API layer directly or calls an HTML tool library (for example, a pop-up window is generated ), those databases can be called through a database abstraction layer (so that you do not have to bind them to a database ).
Key points
For a smart system, there are the following basic points:
1. Independent database
2. Independent presentation layer
3. Easy to modify
4. Object-oriented or at least split into function libraries for calling
These are all my ideas. apart from the above mentioned, there must be other points that you can raise in the forum.
Let's discuss the above points in detail as follows:
1. Independent database
When designing your website, you may not know how much your site is burdened. remember that you cannot bind it to a lightweight database, such as MS access or other resources. Therefore, you should consider the Scalability. if you change the database, you do not need to make too many changes, or even do not need to make any changes, which is the best.
When using php, function calls for various databases are different. you need to encode the database you are using. To change this situation, you can use a database abstraction layer, such as a database developed by PHPLib or others.
2. Independent presentation layer
If you want to develop a truly huge and complex application, you must begin to consider database interface issues, so that you can do a lot less copy and paste work. For example, you need to enable the WAP function for your website 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 poorly designed, you may need to write another one, so that you need to maintain an HTML version and a WAP version at the same time.
For example, when developing a SourceForge site, a large number of users submit their bugs and tasks. At the beginning, we designed it all through web interfaces. Later, under the pressure of some people, we decided to use the 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: HTML library class and database class. The data Class checks whether the input value is valid and performs security detection. the presentation layer only returns true or false based on success/failure. To simplify, this example will not be based on a perfect object model when I have to explain how the base class and other objects extend these base classes. However, I think this example can help you build some concepts.
Example of HTML class
// Connect to the database
Require ("database. php ");
// Common 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
";
// Display the global error string
Echo $ feedback;
}
Echo site_footer ();
?>
Example Data Access Lib
/**
* Controls a bug in updating the database.
* Check the data validity and security, and return true if the data is successful,
* False is returned when a failure occurs.
*
*
*/
Function bug_data_update ($ field1, $ field2, $ field3 ){
// Global string with an error returned
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;
}
// This bug can be updated now
$ Result = db_query ("UPDATE bug ".
"SET field2 = '$ field2 ',".
"Field3 = '$ field3 '".
"WHERE id = '$ field1 '");
// Check whether your statement is successfully executed.
If (! $ Result ){
// Update failed
Return false;
} Else {
Return true;
}
}
?>
3. Easy to modify
Of course, you will not use absolute URLs in the entire application, but I still need to go further. it is best not to use absolute colors, element names, fonts, and other possible options, they should be set in a configuration file and include the file on each page. The style of the site should also be independent-so that you do not need to copy and paste each page. I usually put these HTML in a function, then you can call it as needed.
Database passwords and database connections are also placed in the database abstraction layer.
4. Object-oriented/function
We can split the process into different function calls. Every call does one thing. sometimes it only needs to call other functions and return results.
A good example is to check whether a user has logged in on each page. If you do not use objects or functions, you must modify them on each page when your authentication system changes, rather than simply changing the call of a function in the database. Before writing a piece of code, you need to move it to the library if it needs to be used more than once on the site. Is there any additional?
I'm sure I haven't thought of anything else, so please come up with your ideas. In particular, you have written a very large and complex application. I 'd like to know what kind of system you will establish and what changes you will make if you want to write it again.
