Home>Article>Development Tools> Detailed explanation of how Composer+Git creates a "service class library"
Introduction
I always think that now PHP has progressed into the field of engineering. In the past, PHP developers regarded speed as beauty, and speed and scale were always contradictory. Today's PHP projects, especially larger projects, have gradually evolved to a level that requires both engineering and scale. Engineering a code means evolving into an increasingly complex architecture. For complex architectures, microservices are often a good choice.
I needed this question in a recent project. I need to develop a map service. This service is of course not in the form of a simple class library, but has its own database and its own service interface. In this case, the best option is servitization. Of course, there are many ways to service, such as Thrift, HTTP, etc. But I evaluated the current department environment. PHP is the mainstream language, and the progress of my project is also relatively tight. In my eyes, Thrift, HTTP and other methods all use network protocols to achieve service decoupling. It seems to be a serious solution. I think this approach is not necessary when the project is not clearly in critical condition. The disadvantage of using network protocol servitization is that it introduces significant complexity. This complexity often means investment in manpower, material resources, and time. So I hope to be able to provide a "service class library" in the PHP language for development.
What I am thinking of is PHP’s Composer.
Modification of Composer
Create service class library
First, I need to change my "service class library" from My application (named xxx/main1) is independent. For this independence, I did not choose to create a directory in the application (in fact, I thought about creating a directory such as Services). However, if the code is coupled with the business program, I feel that due to human laziness, it is difficult to control oneself from beginning to end and insist on not using various convenient functions in the application. So my choice is to create a new project in the Git repository and name it xxx/mapService.
composer.json
Now there are two Git projects (xxx/main1 and xxx/mapService). I added the following statement to the composer.json file in main1:
The composer.json in mapService is as follows:
This configuration tells the main1 project that the Git address of mapService needs to be used version of.
Of course you need to pay attention to the following points:
Last use composer update -vvv can download the mapService we need and put it in the vendor directory.
Update and modification
Our editor is now in the main1 project. If we have edited and modified the mapService project, and want to merge it into the master branch of mapService , directly enter the vender/xxx/mapService directory and perform Git corresponding operations. This allows direct code modifications.
Independent configuration
The combination of this structure is only the first step in completing the long march of thousands of miles. What is more important later is that when writing this service, I need to always remember not to use everything in main1, so as to maintain the independence of mapService (independence is one of the necessary conditions for servitization). For example, the first problem I encountered was that the configuration file needs to be independent.
My implementation method is to create a Config class directly in mapService, and the configuration is directly written in this class.
I have always felt that the implementation of this configuration file is a bit frustrating, because in this way, this configuration file enters the Git library. But I really can't think of a better solution. There is a way in Laravel to create Config in Laravel's config folder by implementing ServiceProvider, but this method only applies to Laravel. There is no universality. On the other hand, I think which database the service uses is itself part of the service, and it seems to have nothing to do with putting it in the Git library of the service.
Directory structure
The directory structure is as above
The most important thing about the service is the interface protocol. So create a Contracts folder and interface the provided services.
# The exception handling of the interface should try to use exceptions instead of error codes for interaction. And these exceptions should be customized as much as possible. In this way, there is the possibility of unified processing at the upper level.
Thinking
I position this architectural model as a service-oriented model at the PHP code level. Applicable scenarios should be:
and Git The difference between SubTree and SubModule
In fact, these three methods all use one project as the class library of another project. SubTree and SubModule are Git solutions. Composer is a solution for the PHP language. In addition to the function of adding a project to another project, it also provides solutions such as adding versions and dependency solutions. If your project is in PHP, then using Composer is undoubtedly a better choice.
Later protocol serviceization
If my mapService wants to be protocol service-oriented later, then the mapService project can be simplified into an SDK. For the upper-layer business logic, Just use composer update to update.
Service registration and discovery
The so-called "service class library" I call here does not solve the problem of service registration. I have no way of knowing how many projects use me. services. This may require additional process work.
The above is the detailed content of Detailed explanation of how Composer+Git creates a "service class library". For more information, please follow other related articles on the PHP Chinese website!