PHP is an excellent tool, it can be simple or complex. Different projects should use different PHP.
Small project - simple and direct PHP
Generally for a website with less than 20 functional pages, we can use a very simple framework structure to write it. On this scale, I suggest using a more direct process-oriented coding method. The reason is very simple. There is no need to make N many class files. As a result, there is only one new in the controller. Of course, projects with frequently changing requirements are excluded.
At this level, the advantages of PHP are obvious: rapid development, clear at a glance. The shortcomings are also well hidden.
Medium-sized project - beautifully structured OO PHP
For a medium-sized project, I recommend using a well-designed framework, which can be based on MVC The model encapsulates many underlying operations. Of course, there must be a good, preferably transparent, cache mechanism, so that the OO mechanism we add to adapt to changes can run faster and better.
At this level. PHP's shortcomings began to emerge, such as incomplete OO support (this PHP5 has been greatly improved) and only single-threaded mode. In addition, some peripheral tools are beginning to lack support. For example, PHP does not have good refactoring tools and there is no good unit testing tool integrated into the IDE. The advantages are of course the original rapid development and wide range of available open source resources.
Large-scale projects - expanded and optimized PHP
Large-scale projects here simply refer to distributed projects, that is, your program needs to be deployed on N The server is up. At this level, PHP does lack a lot of support compared to j2ee. I have discussed in detail with shadow on 735 some of the problems that need to be solved if PHP is to be applied on large systems. Of course, these problems are not only problems with the PHP language, but also include problems with peripheral development:
1 PHP page code sharing, after the PHP source code is loaded into the memory once, it is retained in it - this can be done with the APC and Zend optimizers.
2 Data object sharing between PHP pages. A.php and b.php can share a data object, such as an array. This can now be done using serialization, but there will be files io, this can be handled using shared memory or memcached.
3 PHP database connection pool, because in the case of multiple front ends, PHP cannot control the connection to the database, so it is necessary to create a connection pool in front of the database, something similar to sqlrelay. In addition, data caching is also very important. There is a tip for high-pressure development, that is, don’t touch the database if you can.
4 PHP front-end cache system. A transparent and controllable cache mechanism to ensure that the website's pages query the database the least number of times. There are many implementations of this, but I haven't found a particularly good one.
5 After a PHP application successfully solves these problems, it will have no problem coping with slightly greater pressure.
At this level, it is important to integrate PHP java C++ python and the like to make it an efficient system. We can use memcached for distributed memory management, Lucene for full-text retrieval, and ejb containers to place some business logic components. PHP serves as the glue between the front end and the system to quickly and flexibly bond these.