2016-08-22 12 views
0

私は依存性注入を選択する骨を持っています。このようなシンプルなコンセプトが多くの混乱の原因になっているように思えますし、複雑な面では制御不能になっているようです。本当にシンプルなものを維持するには、私はちょうど知りたい:PHPとDICの依存性注入

function someObject() { 
    return new someObject(); 
} 

そして、私はパラメータを渡すことができます。私はこのように、私の依存関係を登録するには、標準的な機能を使用する場合

が、それは良い習慣ですか?

class Dependencies { 
    function someObject($param1) { 
    return new someObject($param1); 
    } 
} 

そして使用:単純なカスタムコンテナクラスを使用することについてどのように最後に

function someObject($param1) { 
    return new someObject($param1); 
} 

class SomeClass { 
    public function __construct(Dependencies $dependencies) { 
    $this->dependencies = $dependencies 
    } 

    public function methodNeedsDependency() { 
    $param1 = 'one'; 
    $task = $this->dependencies->someObject($param1); 
    } 
} 

を、私は私が求めているものを推測し、これはまともな試みでありますa 非常に簡単 DICの実装?あるいは、表面に泡立つ根本的な問題がいくつかありますか?

ありがとうございます!

答えて

1

SomeClassが工場で、何らかの正確な設定でインスタンスを作成するように設計されている場合、これはDICの非常に簡単な実装といえます。

ここに問題がありますか?さて、他のコンストラクタparamsでsomeObjectを作成したいとしましょう。

ソリューション:

  1. は他のparamsを渡します別のSomeClassファクトリを作成します。これは、2つのアプリケーションレイヤー(オブジェクト作成レイヤーとの設定)を混在させる冗長なソリューションです。

  2. パラメタmethodNeedsDependencyパラメタはsomeObjectに渡されます。これはコード設定の作成を延期できるようにするものです。

  3. 最後に、もっとも適切な方法:DICは柔軟性があり、依存関係のあるサービスインスタンスを作成できる必要があり、すべての構成は構成レイヤーに格納する必要があります。懸念の分離 - どのオブジェクトタイプが作成されているのかをDICに認識させようとする。あなたが他の場所に描写した物を作るようにしてください。

あなたは全体のDICのために与えられたクラスのインスタンスを1つだけ持っているしたい場合(たとえば、それはそれの「if」に簡単だが、それが適切に別の回避策だもののように他の問題の多くは、もあります。解決策)または循環参照を使用するもの

このような議論は、「サービスはステートレスでなければならない」のような一般的なアーキテクチャーに関する他の問題と相変わらず続けることができます。もちろん、それはDICのための究極のメガハイパーの答えではないことを覚えておいてください。

+0

シンプルで徹底的な答え...「正確な設定でいくつかのインスタンスを作成する」と言うと、コンテナレベルで設定する必要があるのですか?あるいは、ステップ2で述べたように、それが後で議論として渡されるように、それは妥当であるか? –

+1

設定は... well、config layer :)に与えられます。設定ファイル(YAML、XML、TXT、何でも)を作成します。良い例はSymfonyコンテナの設定です。サービスがそこでどのように定義されているかを見てください。 – mmmm