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

この記事は、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 ファイルに次のステートメントを追加しました。

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

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

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

dev-master は、mapService の master ブランチを直接使用することを意味します。 MapService に他のタグがある場合は、ここでタグ情報を使用できます。
• repositories はプロジェクトのアドレスです
• ここにあるサービスは、弊社が構築した GitLab 上に配置されています
mapService 以下の src フォルダーの名前空間は xxxx\\xxxx\\MapService\\ で、PSR-4 をサポートしています。
• 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 ライブラリにそれを置くこととは関係がないようです。

#ディレクトリ構造

ディレクトリ構造は上記のとおりです

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

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

# インターフェイスの例外処理では、対話のためにエラー コードの代わりに例外を使用するようにする必要があります。そして、これらの例外は可能な限りカスタマイズする必要があります。このようにして、上位レベルでの統一処理の可能性があります。

考え方

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

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

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

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

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

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

サービスの登録と検出

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