Ground Sunlight

Windowsで作る - PHPプログラミングの開発環境

ユーザ用ツール

サイト用ツール


basic-library:league-container:3.3

差分

このページの2つのバージョン間の差分を表示します。

この比較画面にリンクする

両方とも前のリビジョン 前のリビジョン
次のリビジョン
前のリビジョン
basic-library:league-container:3.3 [2020/04/19 16:30]
y2sunlight [テスト2]
basic-library:league-container:3.3 [2020/04/19 22:14] (現在)
y2sunlight
行 1: 行 1:
-> TODO: 編集中 
- 
------ 
- 
 ====== DIコンテナー - League/Container ====== ====== DIコンテナー - League/Container ======
 Version 3.3 ([[https://github.com/thephpleague/container/blob/master/LICENSE.md|MIT License]]) Version 3.3 ([[https://github.com/thephpleague/container/blob/master/LICENSE.md|MIT License]])
行 36: 行 32:
 =====  League/Containerについて ===== =====  League/Containerについて =====
  
-DIコンテナの主な目的はコントローラへの依存性の注入(DI)にあると思います。それはビジネスロジックであるサービスとコントローラやビューとの結合性を如何に疎にするかによって開発効率、保守性やテスト容易性が決まるからに他なりません。しかし「ちょっとした機能のプログラムをPHPでサクサクと実装したい」のが目的のApricotにDIコンテナが果たして必要なのでしょうか。迷いましたが結果的には、ORMやリクエストルーターと同じくシンプルで軽量なものを選定して追加することにしました。現在ではDIコンテナはもはやソフトウェア開発にとって当たり前の部品なのかもしれません。+DIコンテナの主な目的はコントローラへの依存性の注入(DI)にあると思います。それはビジネスロジックであるサービスとコントローラやビューとの結合性を如何に疎にするかによって開発効率、保守性やテスト容易性が決まるからに他なりません。しかし「ちょっとした機能のプログラムをPHPでサクサクと実装したい」のが目的のApricotにDIコンテナが果たして必要なのでしょうか。迷いましたが結果的には、ORMやリクエストルーターと同じくシンプルで軽量なものを選定して追加することにしました。現在ではDIコンテナはもはやソフトウェア開発にとって当たり前の部品なのかもしれません。
  
 DIコンテナにはいくつかの候補があがりました。シンプルで軽量という時点で多機能で秀作なDIコンテナである[[http://php-di.org/|PHP-DI]]は除外されましたが、場合によっては選択してもよかったと思っています。そして次の2つが候補に残りました: DIコンテナにはいくつかの候補があがりました。シンプルで軽量という時点で多機能で秀作なDIコンテナである[[http://php-di.org/|PHP-DI]]は除外されましたが、場合によっては選択してもよかったと思っています。そして次の2つが候補に残りました:
行 83: 行 79:
 ===== テストプログラム ===== ===== テストプログラム =====
  
-パッケージのテストフォルダ(test\league-container\)に、以下のテスト用のコードを作成します。この例は League/Containerのマニュアル に記載されている [[https://container.thephpleague.com/3.x/auto-wiring|Auto Wiringの例題]] を簡素化したものです。+以下の例題は、コンストラクタ・インェクションを3つ方法で行ったものです。最初はDIコンテナーを使用しない場合、2つ目はDIコンテナーを使用した場合、最後にAuto Wiringを使ったものです。テスト用のコードはテストフォルダ(test\league-container\)に、作成します。この例は League/Containerのマニュアル に記載されている [[https://container.thephpleague.com/3.x/auto-wiring|Auto Wiringの例題]] を簡素化したものです。
  
   * Foo.php --- 2つのサービス(BarとBza)を持つFooコントローラ   * Foo.php --- 2つのサービス(BarとBza)を持つFooコントローラ
行 134: 行 130:
 \\ \\
  
-==== 【テスト1】手動によるコンストラクター・インジェクション ====+==== 【テスト1】DIコンテナを使用しない場合 ====
  
 DIコンテナーを使わずに、サービスをコントローラに手動で注入している例です。尚、例題ではComposerによるAutoloadを使用していないので、spl_autoload_register()で代替しています。 DIコンテナーを使わずに、サービスをコントローラに手動で注入している例です。尚、例題ではComposerによるAutoloadを使用していないので、spl_autoload_register()で代替しています。
行 169: 行 165:
 \\ \\
  
-==== テスト2 ====+==== テスト2】DIコンテナを使用する場合 ====
  
-DIコンテナ― によるコンストラクター・インジェクションの例+DIコンテナ― によるコンストラクター・インジェクションの例です。依存関係をクラスコンストラクターに渡すことは、依存性注入の最も簡単な方法です。League/Container ではコンストラクター・インジェクションの他に、セッター・インジェクションとクラスファクトリーによる依存性注入の方法もサポートしています。
  
 <code php index2.php> <code php index2.php>
行 212: 行 208:
 \\ \\
  
-==== テスト3 ====+==== テスト3】Auto Wiringを使用する場合 ====
 League/Containerは **Auto Wiring** 機能をサポートします。これは、コンストラクター引数の型ヒントを調べることにより、オブジェクトとそのすべての依存関係を再帰的に自動的に解決する機能です。但し、注入できるのはオブジェクト型の変数だけです。 League/Containerは **Auto Wiring** 機能をサポートします。これは、コンストラクター引数の型ヒントを調べることにより、オブジェクトとそのすべての依存関係を再帰的に自動的に解決する機能です。但し、注入できるのはオブジェクト型の変数だけです。
  
行 254: 行 250:
 \\ \\
  
-==== テスト4 ====+==== テスト4】Auto Wiringを使用する場合(キャッシュ有効) ====
 デフォルトでは ReflectionContainer は、要求の度にそれを解決しようとします。ReflectionContainer でキャッシュ機能を有効にするには以下のようにcacheResolutions()を使用します。 デフォルトでは ReflectionContainer は、要求の度にそれを解決しようとします。ReflectionContainer でキャッシュ機能を有効にするには以下のようにcacheResolutions()を使用します。
  
basic-library/league-container/3.3.1587281427.txt.gz · 最終更新: 2020/04/19 16:30 by y2sunlight