Not the same project, not the same PHP

Project on the home page to see a article PHP to do the pros and cons of Web projects, their own also to nonsense a few words.

In fact, PHP is a very good tool, it can be simple, but also can be complex. Different items should be used in a different PHP.

Small items-simple and straightforward PHP

Generally for a functional page under 20 of the site, we can use a very simple frame structure to write. On this scale, I suggest the use of a more direct process-oriented coding method, the reason is very simple, there is no need for the class file to get more n, the result controller inside a new is over. Of course, the items with frequent changes in demand are excluded.

At this level, the advantages of PHP are obvious: rapid development, at a glance. Flaws are also hidden very well.

Midsize projects-beautifully structured, oo PHP

For a midsize project, I recommend using a well-designed framework that can be based on an MVC model that encapsulates many of the underlying operations, and of course, there must be a good, transparent cache mechanism, so that the OO mechanism we add to accommodate the changes can run faster and better.

At this level. The disadvantages of PHP are highlighted, such as the incomplete support for OO (this PHP5 has improved a lot), only single-threaded mode. Other peripheral tools are starting to show lack of support, like PHP without good refactoring tools, and no good unit test tools integrated into the IDE. The advantages of course are the original rapid development, a wide range of available open source resources.

Large projects-extended, optimized PHP

Here's a large project that simply refers to a distributed project, which means that your program needs to be deployed on N servers. At this level, PHP really lacks a lot of support compared to Java. I have discussed with shadow in 735 on a number of issues that PHP will need to solve on large systems, not only in the language of PHP, but also in peripheral development:

1 PHP page code sharing, PHP source is loaded into memory once, in which to retain-this with 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 cannot 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, that is, can not move the database do not move the database.

4 PHP Front-End cache system. A transparent and controllable cache mechanism to ensure that Web pages query the database at least a few times. This has a lot to achieve, but no particularly good.

5 last time I said here, the car will stop. Oh ^_^ but I think, a PHP application, a successful solution to these issues, to cope with a slightly larger pressure is no problem.

At this level, we stop talking about the pros and cons, and it's important to combine PHP java C + + Python to make it an efficient system. We can use memcached to do distributed memory management, you can use Lucene for Full-text search, use EJB container to put some business logic components, PHP as the front-end and system glue, fast and flexible to glue these things together.