Composer+Git が「サービスクラスライブラリ」を作成する方法の詳細な説明-composer-php.cn

Composer+Git が「サービスクラスライブラリ」を作成する方法の詳細な説明

藏色散人

リリース： 2022-02-05 05:00:33

転載

2101 人が閲覧しました

この記事は、composer のチュートリアルコラムによって、Composer が Git を組み合わせて「サービスクラスライブラリ」を作成する方法を紹介するために書かれたものです。必要としている！

はじめに

私は今、PHP についていつも思っています。工学の分野にまで進出してきました。かつて、PHP 開発者はスピードを美しさとみなしており、スピードとスケールは常に矛盾していました。今日の PHP プロジェクト、特に大規模プロジェクトは、エンジニアリングと規模の両方を必要とするレベルまで徐々に進化しています。コードをエンジニアリングするということは、ますます複雑なアーキテクチャに進化することを意味します。複雑なアーキテクチャの場合、多くの場合、マイクロサービスが良い選択となります。

最近のプロジェクトでこの質問が必要でした。マップサービスを開発する必要があるのですが、このサービスはもちろん単純なクラスライブラリの形式ではなく、独自のデータベースと独自のサービスインターフェイスを持っています。この場合、最善の選択肢はサービス化です。もちろん、Thrift、HTTP など、サービスにはさまざまな方法があります。しかし、現在の部門の環境を評価してみました。言語は PHP が主流で、プロジェクトの進捗も比較的タイトです。私の目には、Thrift、HTTP、その他のメソッドはすべてネットワークプロトコルを使用してサービスの分離を実現しています。これは深刻な問題であるように見えます。解決。プロジェクトが明らかに危機的な状況にない場合、このアプローチは必要ないと思います。ネットワークプロトコルのサービス化を使用する場合の欠点は、非常に複雑になることです。この複雑さは、多くの場合、人的資源、物的資源、時間への投資を意味します。そこで、開発用に PHP 言語で「サービスクラスライブラリ」を提供できればと考えています。

私が考えているのは、PHP の Composer です。

Composer の変更

サービスクラスライブラリの作成

まず、「サービスクラスライブラリ」を次から変更する必要があります。私のアプリケーション (xxx/main1 という名前) は独立していますが、この独立性のために、アプリケーション内にディレクトリを作成することは選択しませんでした (実際には、Services などのディレクトリを作成することを考えていました)。しかし、コードが業務プログラムと結合していると、人間の怠惰のせいで、最初から最後まで自分を制御することが難しく、アプリケーション内のさまざまな便利な機能を使用しないことに固執するように感じます。したがって、私の選択は、Git リポジトリに新しいプロジェクトを作成し、xxx/mapService という名前を付けることです。

composer.json

これで 2 つの Git プロジェクト (xxx/main1 と xxx/mapService) ができました。main1 のcomposer.json ファイルに次のステートメントを追加しました。

Composer+Git が「サービスクラスライブラリ」を作成する方法の詳細な説明

#mapService の combos.json は次のとおりです:

Composer+Git が「サービスクラスライブラリ」を作成する方法の詳細な説明

この構成は、main1 プロジェクトに、mapService の Git アドレスを伝えます。のバージョンを使用する必要があります。

もちろん、次の点に注意する必要があります。

repositories はプロジェクトのアドレスです
ここにあるサービスは、弊社が構築した GitLab 上に配置されています
mapService は、illuminate/database

最後に使用するコンポーザーの更新を使用します - vvv は、必要な MapService をダウンロードして、ベンダーディレクトリに配置できます。

更新と変更

エディターは main1 プロジェクト内にあります。mapService プロジェクトを編集および変更し、それを main1 プロジェクトのマスターブランチにマージしたい場合は、 mapService では、vender/xxx/mapService ディレクトリに直接入力し、Git に対応する操作を実行します。これにより、コードを直接変更できるようになります。

独立した構成

この構造の組み合わせは、数千マイルの長行を完了するための最初のステップにすぎません。後ほど重要なことは、このサービスを作成するときに、mapService の独立性を維持するために、main1 内のすべてを使用しないように常に注意する必要があることです (独立性はサービス化の必要条件の 1 つです)。たとえば、私が最初に遭遇した問題は、構成ファイルを独立させる必要があるということでした。

私の実装方法は、mapService 内に直接 Config クラスを作成し、このクラスに直接設定を記述します。

この方法でこの構成ファイルが Git ライブラリに組み込まれるため、この構成ファイルの実装は少し面倒だと常々感じていました。しかし、これ以上良い解決策が思いつきません。 LaravelではServiceProviderを実装することでLaravelのconfigフォルダーにConfigを作成する方法がありますが、この方法はLaravelにのみ適用されます。普遍性なんてない。一方、サービスがどのデータベースを使用するかはそれ自体がサービスの一部であり、サービスの Git ライブラリにそれを置くこととは関係がないようです。

#ディレクトリ構造

Composer+Git が「サービスクラスライブラリ」を作成する方法の詳細な説明ディレクトリ構造は上記のとおりです

Configs は設定ファイルを提供します

Contracts はインターフェイスプロトコルを提供します
Exceptions は例外を提供します
Supports はサードパーティのメソッドまたはクラスライブラリを提供します
Models はデータベースとの対話を提供します
Node.php の実装特定のインターフェイス
サービスについて最も重要なことは、インターフェイスプロトコルです。したがって、Contracts フォルダーを作成し、提供されるサービスとインターフェースします。

Composer+Git が「サービスクラスライブラリ」を作成する方法の詳細な説明 # インターフェイスの例外処理では、対話のためにエラーコードの代わりに例外を使用するようにする必要があります。そして、これらの例外は可能な限りカスタマイズする必要があります。このようにして、上位レベルでの統一処理の可能性があります。

考え方

私は、このアーキテクチャモデルを PHP コードレベルのサービス指向モデルとして位置づけます。該当するシナリオは次のとおりです。

#サービス指向の後の計画

#マンパワーと初期段階の思考の両方が迅速な開発を維持することを希望するシナリオ
#と Git SubTree と SubModule の違い

実際、これら 3 つのメソッドはすべて、1 つのプロジェクトを別のプロジェクトのクラスライブラリとして使用します。 SubTree と SubModule は Git ソリューションです。 Composer は PHP 言語のソリューションであり、プロジェクトを別のプロジェクトに追加する機能に加え、バージョンの追加や依存関係の解決などのソリューションを提供します。プロジェクトが PHP である場合は、Composer を使用することが間違いなくより良い選択です。

後のプロトコルサービス化

mapService を後でプロトコルサービス指向にしたい場合は、mapService プロジェクトを SDK に簡素化できます。ロジック、更新するには、composer update を使用するだけです。

サービスの登録と検出

ここで私が呼ぶいわゆる「サービスクラスライブラリ」は、サービス登録の問題を解決しません。その方法を知る方法はありません。多くのプロジェクトが私のサービスを使用しています。これには追加のプロセス作業が必要になる場合があります。

以上がComposer+Git が「サービスクラスライブラリ」を作成する方法の詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。