PHP is a very good tool, it can be simple, can also be complex. Not the same project, should use different PHP.
Small project-Simple and direct PHP
Generally for a function page under 20 of the site, we can use a very simple framework structure to write. In this scale, I suggest that the use of a more direct process-oriented coding method, the reason is very simple, there is no need to get the class file more than N, the result of a controller inside a new will be finished. Of course, except for items that require frequent changes.
At this level, the advantages of PHP are obvious: rapid development, at a glance. Shortcomings are also well hidden.
Midsize projects-beautifully structured, oo PHP
For a medium-sized project, I recommend using a well-designed framework that can be based on the MVC model, encapsulating many of the underlying operations, and, of course, having a good, preferably transparent cache mechanism, so that the OO mechanism we join to adapt to change can run faster and better.
At this level. PHP's shortcomings began to emerge, like the incomplete support for OO (this PHP5 has a great improvement), only single-threaded mode. Other peripheral tools are beginning to show a lack of support, like PHP without good refactoring tools and no good integration into the IDE's unit testing tools. The advantages are of course the original rapid development, a wide range of open source resources available.
Large projects-expanded, optimized PHP
The large project here, simply refers to the distributed project, that is, your program needs to be deployed on the N server. At this level, PHP does not have much support compared to the Java EE. I have discussed with shadow in detail the problems that PHP needs to solve on a large system in 735, of course, these problems are not only the language of PHP, but also the problem of peripheral development:
1 PHP page code sharing, PHP source code is loaded into memory once, in which to retain-this with the APC and Zend Optimizer can be done.
2 data object sharing between PHP pages, a.php and b.php can share a data object, such as an array, which can now be serialized, but there will be file Io, which can be handled with shared memory or memcached.
3 PHP database connection pool, because in the case of multiple front-end, PHP can not control the connection to the database, so need to make a connection pool in front of the database, similar to sqlrelay things. In addition the data cache is also very important, the big pressure development has a tip, is can not move the database to do not move the database.
4 PHP Front-end cache system. A transparent, controllable cache mechanism that ensures that pages of a Web site query the database for a minimum number of times. There are many implementations of this, but nothing particularly good has been found.
51 PHP applications, the successful solution to adjust these problems, to cope with a slightly larger pressure is no problem.
At this level, it's important to combine PHP java C + + python into an efficient system. We can use memcached to do distributed memory management, can use Lucene for full-text retrieval, with EJB container to put some business logic components, PHP as the front end and the system of glue, quickly and flexibly glue these together.
http://www.bkjia.com/PHPjc/446971.html www.bkjia.com true http://www.bkjia.com/PHPjc/446971.html techarticle PHP is a very good tool, it can be simple, can also be complex. Not the same project, should use different PHP. Small items-simple and straightforward PHP for a feature page ...