3

ninject をセットアップしようとしている .Net 4.0 WCF サービスがあります。ninjectの WCF拡張機能をダウンロードし、TimeService の例を調べました。すべてが十分に単純に見えますが、依存関係を手動で注入するパラメーターのないコンストラクターがあるため、ninject がどのように正しく機能しているかわかりません。

 public TimeService()
    : this(new SystemClock())
{
}

public TimeService( ISystemClock systemClock )
{
    _systemClock = systemClock;
}

私が理解している限り、このコードは決して ninject バインディングを使用しません。パラメータを指定しない場合、最初のコンストラクターは 2 番目のコンストラクターを呼び出します。テスト中にモック オブジェクトを渡すと、2 番目のコンストラクターが呼び出されます。私は WCF と ninject の両方にかなり慣れていないので、明らかな何かが欠けている場合は申し訳ありません!

誰でも説明できますか？

ありがとう

4

1 に答える 1

2

デフォルトでは、Ninject は最大数のパラメーターを持つコンストラクターを選択します。これには、埋めるのに十分なバインディング情報があります。したがって、Ninject モジュールが ISystemClock 実装を提供できる場合、Ninject は 2 番目のコンストラクターを優先します。

ここで示しているパターンは、注入された依存関係を許可する場合によく使用されますが、特定の依存関係がない場合にフォールバックする論理的なデフォルトがあります。ご指摘のとおり、単体テスト時に独自の ISystemClock モックを提供できます。これにより、決定論的テストの利点が得られます。同様に、何らかの理由で ISystemClock のカスタム実装を提供したい場合は、一致するバインディングを使用して Ninject モジュールをセットアップできます。

一方、ほとんどの目的では、ストック SystemClock 実装を使用するのがおそらく最適な実装であるため、クラスが機能するために ISystemClock バインディングを強制的に設定するのではなく、SystemClock を次のように使用する代替コンストラクターが提供されます。デフォルトの実装。ISystemClock サービスのバインディングを指定していない場合、Ninject はこのコンストラクターにフォールバックします。

編集

この特定のケースでは、実行されていない理由は、TimeService クラスの次の属性によるものです。

[ServiceBehavior( InstanceContextMode = InstanceContextMode.Single )]

ここで何が起こっているのか完全には理解できませんが、Ninject を使用してサービスを作成することを何らかの形で妨げています。この行をコメントアウトすると、期待どおりに動作するはずです。

于 2010-11-02T15:30:50.007 に答える