[Self-view] how to select a PHP framework?

[Self-view] how to select a PHP framework? How to select a PHP framework?

This is a frequently used Question for interviews. Therefore, when SF saw this question, it took some time to answer it. Here we will make some preparations and supplements.

Most of the time, it is a good idea to discuss the issue from the perspective concept. Framework isTeamInProjectThe development framework selected at the initial stage, or the public logic extracted during the long-term development process. Therefore, both the initial selection of frameworks, the mid-process reconstruction of frameworks, and the need to withdraw from the internal framework of the team should be comprehensively considered from the following three perspectives:

• Team

• Project

• Framework itself

Team members & future team members & local career market conditions

If you are the only one in the present and future of the team (such as your toy project), you can select the one you want most. But if this is not the case, you 'd better first understand the common frameworks on the market and then forget your personal preferences.

Learn about the current situation of your team members, consider the future development speed of your team, the potential of future team members, and the status of your local career market. For example, Laravel is often a good choice, but if you are in a small city with underdeveloped industries, the team must develop rapidly and attract a large number of people, choosing Laravel will soon bring you into the "composer and modern PHP skills training courses" dilemma, while some more "grounded" frameworks will allow your team to expand rapidly, quickly meet business development needs

Project lifecycle & future evolution

Some projects, as your company's main business, require long-term maintenance and continuous iteration. Other projects may be used as corner and transition projects, and there may be no subsequent requirements after completion. Finally, there are some outsourcing/outsourcing projects. after delivery, there will be no need/follow-up needs to be another project.

There are more large projects and more demands. if there is a third type, you do not need to consider the future evolution, then the scalability of the framework will be sacrificed (in exchange for development speed or other benefits ), for example, the secondary development of finished products can be considered. For a small project, if your company's main business is continuous iteration, you must carefully consider the scalability of the framework even if the workload is small.

So what is the scalability of the framework? Is CI a well-scalable framework? Is ZendFramework1/2 a framework with good scalability?

The answer is, looking at the future evolution. In the future, some projects are under heavy access traffic, some are under heavy data volume and frequent retrieval, while some are under fast iteration of demands, frequent changes, and short cycles. The more common the problems faced by the project, the less repetitive the framework of preset solutions. the more extreme the problems faced by the project, then the lightweight frameworks may be more suitable for your team to study the solution and connect it to the framework. In addition, the longer the project maintenance time, the harder it is to predict changes, the larger the risk of adopting a framework with preset solutions (the smaller the probability that preset solutions can solve each of your problems)

Basic qualities of the framework itself

Performance and running score. Except for the two C implementation frameworks of phalcon and Yaf, other frameworks should be considered as fast. In addition, unless you host something like changing the PHP framework on Sina Weibo, or you manage more than 100 project web machines, ignore the performance factors of the PHP framework.

This API is compatible with composer. This is a double-edged sword. I have already talked about how to look at this feature.

Security. Some frameworks even have their own security vulnerabilities. In addition, if some security aspects are provided at the framework level, it is recommended that you simply read the code. sometimes it may be better to write it yourself.

Functionality. That is, the number and quality of preset solutions have been mentioned earlier.

Degree of modularization. Can each part of the framework be customized? what is the cost of customization. The other aspect is whether all parts of the framework can run without the framework.

Expressive ability (the amount of code required for business functions). these three features (expressive ability, functionality, and modularity) conflict with each other and cannot achieve both of them. A framework with rich functions and a high degree of modularization can be customized and replaced at will, and a bunch of common business code should also be written. A framework that can write a lot of functions in one sentence is often not ideal in modularity and is not easy to customize. High degree of modularization, but not business code? Long-winded frameworks often have no rich preset functions.

The surrounding ecosystem, activity level, and compatibility. There is still room for growth and improvement in an active framework. However, if the framework is too active, application compatibility may fail. Another indicator is the surrounding ecosystem. Is there anyone else who develops peripheral modules/plug-ins based on this framework, as well as the richness of the documentation and the solutions that can be easily found after a problem occurs.

"No moves, no moves, no moves" -- talking about composer and PSR-7 and the PHP framework in my mind for the next decade

(The content of this section is only my personal judgment. In addition, based on China's national conditions, foreigners may enjoy this in the future)

PHP is a relatively old language, and the PHP framework is also a fairly old concept. I think the Node. js community next door demonstrates the true form of the "web Framework. With the dependency solution npm as the core and the middleware architecture represented by connect to express as the skeleton, there are countless middleware around the stars. The middleware architecture sets standard interfaces for web requests and responses. other projects around the middleware develop various functions based on these interfaces. What engineers need to do is to find the right middleware to plug into the project, or write the middleware suitable for their own situation (of course, it is best to open the source to return to the community ). So you will find that the projects that are equivalent to the "PHP framework" concept are basically not working (sails is already the best ?)

This is my judgment on the future PHP framework. The big and comprehensive "PHP framework" era has passed. Don't use composer, or pretend that those frameworks that use composer have no future. Composer-based, modular componentized projects will generate amazing productivity in the future under the unified strong input and output standards. Symfony/http-foundation is a good choice, and the community has corresponding middleware efforts. But at present, it seems that the long-awaited PSR-7 is more likely to become the winner of the future. With a strong standard and deconstruct middleware ecosystem, the community is fully competitive, and developers have full options. The A2 framework view layer is very bad, but the routing is very beautiful, which of the following statements about B2 framework routing is useful but the view is poor? The next generation A3 and B3 support the same PSR-7, take home stitching just like!

Ad Time: Based on this judgment, I spent some time exploring my middleware architecture mcfog/nimo in the absence of many stars for the PHP port of connect.

Address: http://inside.mcfog.wang/2015/09/ichizon-d/