[one's own] how to choose PHP Framework?

How to choose PHP Framework?

This question is the common hand problem that I interview, so in the SF see this Question Time, take time to answer a bit. Here do some sorting and replenishment.

In many cases, it is a good idea to discuss issues from the point of view of key concepts. A framework is a development framework selected by the team in the early stages of a project , or a common logic that is refined during a long-term development process. Therefore, whether it is the initial selection of the framework, is the halfway restructuring to replace the framework, or need to draw away from within the team's own framework, should be considered in the following three aspects of a comprehensive

• Team

• Project

• The framework itself

Team members & Future team members & local job market situation

If you are the only person in your team now and in the future (like your own toy project), choose what you want to use most. But as long as it's not the case, you'd better start by understanding the various frameworks that are common on the market and then forget your personal preferences.

Learn about the current situation of your team members, consider the future speed of your team, what team members might be joining in the future, and the job market situation in your location. For example, Laravel is often a good choice, but if you are in a small, underdeveloped city, and the team has to develop a large number of people at a high speed, choosing laravel may soon put you in the "Composer and modern PHP skills training" dilemma, while some more "grounded gas" Framework allows your team to quickly expand to meet the needs of business development

Project Life cycle & Future Evolution direction

Some projects, as your company's main business is the need for long-term maintenance, continuous iteration. Other projects may be a marginal, transitional project, and there will be no further requirements to be completed. Finally there are some outsourcing/outsourcing projects, after delivery there will be no demand/follow-up requirements can be when another project.

The larger the project, the more demand, if the third, regardless of future evolution, then the scalability of the framework can be sacrificed (in exchange for development speed or other benefits), such as the choice based on some two development of the finished product can be considered. Again small projects, if your company's main business, continuous iteration, then even if the workload is small, you must carefully consider the extensibility of the framework.

So, what is the extensibility of the framework? Is CI a very extensible framework? Is ZENDFRAMEWORK1/2 a very extensible framework?

The answer is, look at the future evolution direction. Some projects in the future of pressure in the traffic, some pressure in the large number of data retrieval frequently, there are project pressure in demand iteration fast, frequent changes and short cycle. The more common the problems with the project, the more likely the framework of the various solutions may be to reduce the number of repetitive wheels, whereas the more extreme the problem is, the lighter frameworks may be more suitable for your team to research the solution to the framework. In addition, the longer the project is maintained, the more difficult the changes are to predict, and the greater the risk of adopting a framework that presets the various solutions (the probability that the preset solution will solve your problem is getting smaller)

Basic qualities of the framework itself

Performance and running points. In addition to the Phalcon and YAF two C implementations of the framework, other frameworks are considered as fast. And unless you're hosting something like Sina Weibo changing the PHP framework, or unless you're managing more than 100 Project Web machines, ignore the PHP framework's performance factors

PSR and composer Affinity. It's a double-edged sword, and we've talked about how to look at this trait before.

Security. Some frameworks even themselves have security flaws that don't say much. In addition, if the framework level provides some security aspects, it is advisable to read the code briefly, sometimes it may not be as good as writing.

Functionality. That is, the number and quality of pre-defined solutions, as mentioned earlier.

Degree of modularity. Whether the various parts within the framework can be customized, and how expensive the customization is. Another angle is whether the various parts of the frame can run out of the frame.

The ability to express (how much code is required for business functions), these three features (expressive, functional, modular) conflict with each other and fail to achieve the same level of three. Feature-rich, modular and high can be arbitrarily customized, replace the framework, often common business code to write a bunch. A sentence can write a lot of functions of the framework, often the degree of modularity is not ideal, not easy to customize. Modularity is high, and business code does not have a framework that is often not rich in preset functions.

The surrounding ecology and activity level as well as compatibility. There is room for growth and improvement in the active framework, but being overly active can sometimes lead to incompatible applications. Another indicator is the surrounding ecology, there is no other people based on this framework to develop some of the surrounding modules/plugins and other things, as well as the richness of the document, the problem can be easily found after the solution.

"No recruit wins, no strokes"

--On the PHP framework of composer and psr-7 and my mind for the next ten years

(This section is only my personal judgment, in addition, based on China's national conditions, the future may also be foreigners enjoy first)

PHP is a relatively old language, and the PHP framework is a pretty old concept. I think the Nodejs community next door is a good example of what a real "web framework" should be. With the dependency solution NPM as its core, connect to express is the backbone of the middleware architecture, surrounded by a myriad of middleware around the star. The middleware architecture sets the standard interface for Web requests and responses, and other projects around them develop a variety of functions based on these interfaces. What engineers have to do is to find the right middleware to put into the project, or to write their own middleware (preferably open source to return the community). So you will find that the equivalent of the "PHP framework" concept of those projects is basically unworkable (sails is already doing the best?). ）

This is my judgment of the future PHP framework. Chatty's "PHP framework" era has passed. Do not composer, or pretend that you use composer of those frameworks without the future. Based on the composer, modular component of the project, in the future under the strong input and output standards unified, will explode an astonishing productivity. Symfony/http-foundation is a good choice, the community also has the corresponding middleware efforts. But for now, the long-conceived PSR-7 are more likely to be the winners of the future. There is a strong standard and deconstruction of the middleware ecosystem, the community can fully compete, developers have the full choice, A2 frame view layer of the big rotten but the route is very beautiful, B2 framework routing good But the view is bad? The next generation of A3 and B3 are the same support PSR-7, take home their own stitching on good!

Ad time: Based on this judgment, the PHP porting of Connect does not have many star cases, and I spent some time mcfog/nimo my middleware architecture, welcoming onlookers and star

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

