Clever Geek Handbook

Yii2の代替プロジェクト組織



Yii2で今すぐプロジェクトを作成することはどのように提案されていますか？ 基本または高度なプロジェクトテンプレートを選択し、自分自身をフォークして、そこに書き込み、コミットします。 バム！ コピーと貼り付けが行われ、プロジェクトとテンプレートは個別に開発されています。 テンプレートの修正は行われず、もちろんyii2-app-basic



はタスク固有の修正を行いません。 これが一番の問題です。







プロジェクトはYii2でどのように拡大していますか？ 適切な拡張機能を選択し、コンポーザーを使用して接続します。 READMEでこの展開の構成の例を見つけ、アプリケーションの構成にコピーして貼り付けます。 おっと...もう一度コピーして貼り付けます。 次のようなさまざまな側面を登ります：大規模なプロジェクトでは、多くの拡張機能が使用されます-アプリケーションの構成が巨大になり、単に読みにくくなります。 これが問題2です。







これらの問題はどのように関係していますか？ 最初の問題は次のように解決されます。再利用されたコードを選択し、拡張機能に変換します。 こんにちは。拡張機能には独自の設定があります-2番目の問題があります。







これらの問題は、基本的に同じプロジェクトを多数/複数、ただし大きな/小さな変更を必要とする場合に、再利用可能なソリューションにとって最も深刻です。 さらに、コピーと貼り付けをなくしてコードを再利用することで、誰も悩むことはありません。







これらの問題に対する解決策を共有したいと思います。









プラグインシステム



私は自分の魂を苦しめず、その本質をすぐに説明するので、もしあれば、最後まで読まずにすぐに吐き出すのが便利です。







したがって、解決策は次のとおりです。プラグインシステムを使用します。最初からプラグインとしてプロジェクトを作成し（構成を使用した拡張）、プロジェクトをプラグインに分割し、プラグイン構成からアプリケーション構成を自動的に収集します。







ここで一時停止し、プラグインと呼ぶものを説明する必要があります。 Yii2にはYii2拡張機能が用意されており 、再利用可能なコードを整理して、作曲家とプロジェクトに接続することができます。 しかし、多少複雑な拡張には設定が必要です。 そして、ここではフレームワークは役に立ちません。 拡張機能の作成者には2つのオプションがあります。









私はすでに最初の最初のオプションを批判しましたが、2番目のオプションを取り上げます。









一般に、さまざまなオプションで苦しめられたいくつかの反復を経た後、急進的な決定が生まれました-アプリケーションの外部で起動する前でも構成を収集することです（うーん、それは簡単で明白なようですが、ご存知のように、良い考えは後で来ます）。 作曲家のプラグインを使用してアセンブルするのが最も便利であることが判明しました;それから、プロジェクトの依存関係の階層全体に便利にアクセスできます。 そこで、 composer-config-pluginが判明しました。







Composer Configプラグイン



Composer-config-pluginは非常に簡単に機能します。









以下の行がcomposer.json



拡張機能に追加されます（プラグインになります）。 







  "extra": { "config-plugin": { "web": "src/config/web.php" } }


これは、 web



と呼ばれる設定内のsrc/config/web.php



ファイルの内容をフリーズすることを意味します。 そして、このファイルでは、プラグインがアプリケーションの構成に追加したいもの（国際化構成など）になります。 







 <?php return [ 'components' => [ 'i18n' => [ 'translations' => [ 'my-category' => [ 'class' => \yii\i18n\PhpMessageSource::class, 'basePath' => '@myvendor/myplugin/messages', ], ], ], ], ];


dotenv



、 defines



およびparams



など、特別なものを含む任意の数の構成があります。 構成は次の順序で処理されます。









これにより、前の手順で取得した値を後続のすべての値で使用できます。







つまり、環境変数を使用して定数を割り当てることができます。 定数と環境変数を使用して、パラメーターを割り当てることができます。 そして、セット全体：パラメータ、定数、環境変数を設定で使用できます。







それだけです！ composer-config-plugin



は、すべてのcomposer-config-plugin



配列をyii\helpers\ArrayHelper::merge



関数の類似物と単純にマージyii\helpers\ArrayHelper::merge



ます。 当然、構成は正しい順序でマージされます-誰が誰を取得しているかを考慮して、各パケットの構成が依存関係の後にマージされ、指定された値を上書きできるようにします。 つまり 最上位のパッケージは設定を完全に制御し、すべての値を制御します。プラグインはデフォルト値のみを設定します。 一般に、このプロセスはyii2-app-advanced



の構成のアセンブリを大規模にのみ繰り返します。







アプリケーションでの使用は簡単ですweb/index.php



追加しweb/index.php



。 







 $config = require hiqdev\composer\config\Builder::path('web'); (new yii\web\Application($config))->run();


github： hiqdev / composer-config-pluginで質問と同様に、より多くの情報と例を見つけることができます。







hiqdev / yii2-yandex-metrikaプラグインの非常に簡単な例。 しかし、このアプローチの機能を明確に示しています。 Yandex.Metricaカウンターを取得するには、プラグインを登録してyandexMetrika.id



パラメーターを設定するyandexMetrika.id



です。 それだけです！ 設定に何かをコピーしたり、ウィジェットをレイアウトに追加したりする必要はありません-作業中のコードに触れる必要はありません。 プラグインは、既存のコードを変更せずにシステムを拡張できる機能の不可欠な部分です。







-何？ 古い機能を壊さずに新しい機能を作成できますか？！

-はい。

-かっこいい！ 今、あなたはテストを書くことができませんか？

-いいえ...起こりません...







合計で、 composer-config-plugin



はcomposer-config-plugin



のシステムを提供し、いわゆる「小さなアーキテクチャ形式」を再利用する問題を解決します。 大事な再利用可能なプロジェクトの組織である主なものに戻る時が来ました。 提案されたソリューションを繰り返し、明確にします。正しい階層に編成されたプラグインのシステムとしてプロジェクトを作成します。







パッケージ階層



プロジェクトを整理するための最も簡単なオプションはこれです：私たちのプロジェクトは作曲家フレームワークとサードパーティの拡張機能（私たちのプロジェクトの一部ではない「サードパーティ」の拡張機能と呼ばれます）、つまり パッケージ（リポジトリ）のこのような単純な階層が判明します。









実際の運用結果に基づいてテストおよび破棄された組織の中間オプションをすべてスキップし、すぐに最適な階層に進みます。









階層には、誰が誰を獲得しているか、つまり ルートはメインプロジェクトの要求であり、メインプロジェクトは基本プロジェクトであり、基本プロジェクトはフレームワークです。







-すごい！ 楽にしてください！ 「ルート」および「ベースプロジェクト」とは何ですか？







申し訳ありませんが、自分ですべてを思いついたので、適切な用語が見つかりませんでした。サイクリングしなければなりませんでした。最高のオプションに感謝します。







「ルート」とは、プロジェクトのこの特定の実施形態に固有のコード、構成、およびその他のファイルを含む最も外部のパッケージを意味します。このオプションがメインプロジェクトとどのように異なるかです。 理想的には、ほんの数個のファイルが含まれており、さらに以下に記載されています。







「基本プロジェクト」は、このスキームでyii2-app-basic



がyii2-app-basic



するものです。 つまり いくつかの基本機能を実装し、プラグインとして設計された再利用されたアプリケーションフレームワーク。 この部分はオプションですが、非常に便利です。 自分で行う必要はありませんyii2-app-basic



開発中にコミュニティで開発できます。 HiSiteの開発中です。詳細は以下をご覧ください。







したがって、パッケージは構成階層を形成します-外部パッケージは内部パッケージを使用し、主にその動作を再利用しますが、その詳細を再定義します。 「ルート」はメインプロジェクト、メインプロジェクト-基本、基本プロジェクト-フレームワークを使用および改良します。







コードを整理することについてのみ話していることを明確にする必要があります。 コードのパッケージ/プラグインへの分割について。 もちろん、パッケージへの分割に関係なく、プロジェクトの階層へのアーキテクチャ分割は、互いに補完することができます。 たとえば、ドメインロジックを別のパッケージに配置して、異なるプロジェクト間で再利用できます。







-ああ！ 例が必要です！







たとえば、名刺サイトをストリームに作成します。 基本的な機能はどこでも同じですが、追加料金がかかる機能があります。たとえば、ディレクトリと、もちろんサイトの外観（テーマ）とパラメーターの束が異なります。 これは、次のようなパッケージ階層に編成できます。









私はアメリカを発見していないことを願っています。多かれ少なかれ彼らはプロジェクトを部分に分けています。 おそらく、おそらく「ルート」なし。 その有用性を伝えようと思います。







根



「ルート」には 、テンプレートからコピーして、プロジェクトのこのインストール用に構成する必要があるファイルがいくつかあります。 次の3つのファイルで対応することが可能であり、望ましいことです。









パスワードは.env



に入れて、 params.php



ようにparams.php



使用できます。 







 return [ 'db.password' => $_ENV['DB_PASSWORD'], ];


.env



の「 .env



消化性」を.env



.env



持ち帰りに最適な申請者は、他の（PHPではない）テクノロジーで使用されるパラメーターです。







もちろん、 「ルート」に特定の設定を配置することもできますし、コピーインペーストの対象ではなく、このインストール専用のコードを配置することもできます。 コピー＆ペーストを見るとすぐに、それが怖いのが好きではありません。プラグインに持って行きます。







アプリケーションの機能に必要な残りのファイルとディレクトリ（ web/assets/



、 web/index.php



）は標準です。それらを作成し、「collector」（ビルドツール、タスクランナー）に権限を割り当てる必要があります。







実際、 「ルート」はステロイドのparams-local.php



です。 プロジェクトの特定のインストールと一般的な再利用可能なコードの違いに焦点を当てています。 ルートの下にリポジトリを作成し、プライベートgit-serverに保存するので、そこに秘密もコミットします（ただし、これは全体的なトピックです）。 他のすべてのパッケージは、GitHubで公開されています。 ルートでcomposer.lock



をコミットするので、プロジェクトを別のサーバーに移動するには、 composer create-project



実行するだけです（Dockerの方が良いことはわかっていますが、次回はさらに詳しくなります）。







-もっと具体的に教えてください。 最後にコードを見せてください！







HiSiteおよびAsset Packagist



私たちが開発している「基本的なアプリケーション」の 1つであるHiSite hiqdev / hisite-は、コピーペーストよりもコードを再利用する利点をすべて提供する、プラグインとしてのみ作成されるyii2-app-basic,



ような典型的なサイトの基盤です：









ここのHiSiteプロジェクトのルートテンプレートはhiqdev / hisite-templateです。







依存関係の階層は次のようになります。









ルートREADMEには、プロジェクトを立ち上げる方法が記載されています-composer composer create-project



plus configuration settings。 composer.json



ルートのプラグインとhiqdev / yii2-thememanagerテーマライブラリの両方の実装のおかげで、 yii2-theme-flat



をyii2-theme-original



に変更し、 composer update



を実行composer update



と、サイトが新しいテーマに変更されます。 とても簡単です。







例として適切な別の実際の作業プロジェクトは、このアプローチを使用して作成され、GitHub- Asset Packagist -packagist互換リポジトリで完全に利用可能です。これにより、BowerおよびNPMパッケージをネイティブコンポーザーパッケージとしてインストールできます。







依存関係の階層は次のようになります。









プロジェクトの昇格方法の詳細は、 READMEルートに記載されています 。







要約する



このトピックは広範囲にわたるため、多くの詳細を省略する必要がありました。 一般的なアイデアを伝えることができたと思います。 ここでも、導入された用語を使用します。









説明したアプローチを約1年間使用し、印象は最もポジティブです-髪は柔らかく絹のようになりました：リベットプラグインを簡単かつ自然に分離し、 100 +を停止することはありません、新しい機能が必要です-新しいプラグインを作成します。







このアプローチは、何らかの形で他のフレームワークや言語にも適用できます...ああ、Ostapは苦しみました...今日はこれで十分です！ ご清聴ありがとうございました。 継続する。







PS



Symfony 4についてのFabien Potensier （Symfonyの著者） による 一連の 記事は、 私にそのような大量のテキストを書くように促しました 。与える：







アプリケーションを簡単に作成および進化させる新しい方法

アプリケーションを簡単に作成および開発するための新しい方法

©ファビアン・ポテンシエ







一般に、1つではなく、提起された問題はフレームワークにとって非常に重要だと思います。







Yiiが大好きです。 Yiiをもっと良くしましょう！







More articles:


All Articles