問題タブ [ninject-extensions]

NuGetのNinject3.0.1.10とninject.extensions.factory3.0.1.0を使用しています-「実際の」シナリオでは、（手動でIFooをバインドするのではなく）ninject.extensions.conventionsも使用しますが、質問を単純化するために、これを避けてください。

私はIFooインターフェースとその複数の実装を持っており、それぞれがGen1とGen2と呼ばれる子名前空間とサブフォルダーの下にあります。指定されたパラメーター（文字列、列挙型など）に基づいてIFooを返すことを目的としたIFooFactoryインターフェイスがあります。

この例では、列挙型を使用してわかりやすくしています。最初は文字列バージョンを作成しましたが、文字列などのより任意のパラメーターを渡すことに対する反対意見は、問題を混乱させるだけだと感じました。

さて、このような実装をコンシューマーに「選択」させることは、理想的には存在しないカップリングの形式であることを理解していますが、私見では、Ninjectがすでにサポートしている名前付きバインディングと同じレベルのカップリングです。実装に属性を追加することは避けたかったのですが、GetGen1 / GetGen2 / etcメソッドをファクトリインターフェイスに含めることは、これに非常に適しています。呼び出し先のメソッドに入力をマップするために、どこかのスイッチを介してOCPに違反することになります。 （または手動でリフレクションを使用）

可能であれば避けたいと思っている完全な/動作するコードはここにあります：https ：//gist.github.com/4549677

2つのアプローチを使用します。

1. 列挙型のスイッチが渡されたOCPに違反する手動のファクトリ実装
2. IInstanceProviderのインスタンスでファクトリ拡張を使用します（GetInstanceをオーバーライドするためにStandardInstanceProviderをサブクラス化します）。

2番目のアプローチは、これを機能させるために「正しい方法」に「近い」可能性があるように見えますが、1）作業を行うためにカーネルへの参照を保持します。これはおそらく悪い考えであり、2）呼び出し中にすべてのIFooバインディングを検索したときに、IFooのバインディングに具体的なタイプが見つかりませんでした。現在、GetAllを実行しているため、このシナリオに必要な数よりもN-1多いインスタンスをインスタンス化します。

明らかに、私は何かが欠けています。MVC アプリケーションがあり、Ninject 3 と MVC3 拡張機能をインストールしました (ただし、MVC4 を実行しています)。SiteSettingsプロジェクト全体で参照されるクラスがあります。これは次のようになります。

次のようにデータ永続化オブジェクトを作成しました。

...そして、私はNinjectWebCommon.csこのように見えます：

依存性注入のすべての要件を満たしているように思えます。私Global.asax.cs Application_Start()はこのように見えます：

...それでも、必要なデータを収集しようとすると、SiteSettingsクラスには常に null があります。IUnitOfWorkFactory

私は何を間違っていますか？すべての例がそうであるべきだと示唆しているように見えますが、私は愛されていません.

アップデート

Bassam Mehanni のアドバイスを使用して、DataPersisterクラスを次のように書き直しました。

...しかしもちろん、私のSiteSettingsクラスは私のパラメーターなしのコンストラクターについて不平を言っています。それについて私は何をすべきですか？

更新 2

続けて、DataPersisterクラスを次のように書き直しました。

SiteSettings次に、クラスを次のように書き直しました。

これはうまくいかないのですか？そうではないからです。クラスはDataPersister常にパラメーターなしのコンストラクターで呼び出されます。私のカーネルバインディングは次のようになります:

私が見逃しているものは他にありますか？これは非常にイライラしています。

私はasp.netでアプリを開発しています.Ninject Interceptorを実装しており、サービスをバインド/登録しています.

このサービスのメソッドを呼び出しているとき

メソッド BeforeInvoke が TimeInterceptor で 2 回呼び出されています。なんで？

スコープ、コンテキスト、名前付きバインディング（およびアクティベーションブロック？）のNinjectの概念を分離して、概念レベルで明確に説明できますか？

例として、データベースからデータレコードをロードし、レコードごとにNinjectファクトリ拡張を介して「ワーカー」を構築するサービスがあります。サービスと個々のワーカーの両方が、EntityFrameworkのオブジェクトコンテキストを使用してデータベースと対話します。ObjectContextは、コンストラクターを介して両方に注入されます（他の共有依存関係も同様です）。現在はシングルスレッドですが、最終的にはワーカーは独自のスレッドで並行して実行する必要があるため、独自のObjectContextインスタンスと明示的な開始/破棄のライフサイクルが必要になります。ObjectContextインスタンスは、ワーカーの「作業単位」の期間中共有する必要があります（したがって、ワーカーが使用する複数のリポジトリーに注入されるため、一時的ではありません）。私はこの機能を取得しようとして立ち往生しています。

私は素朴にこのようなものが欲しかった（名前付きスコープとコンテキスト保存拡張機能を使用）：

これは明らかに（少なくともNinjectユーザーには明らかです）、MyDbContextが原因で「複数の一致するバインディング...」エラーが発生します。さらに多くのことを読んだ後、私はおそらくワーカーとそのObjectContextに名前付きバインディングを使用する必要があると思います。ワーカーが終了したときにObjectContextを明示的に破棄できるように（そして、スコープの処理からdisposeメソッドを使用できるように）、スコープも必要だと思います。

いずれにせよ、私はまだほとんど推測しているので、誰かがNinjectでこれらの概念を明確にできることを期待して、この質問を投稿しています。

次のインターフェイスをToFactory()バインディングとして使用しています。

バインドすると、クラスを正常に作成できますが、デリゲート内のターゲット/パラメーター オブジェクトを参照する内部の NinjectToFactory()によって登録、登録解除、および valueGetter パラメーターが保持されるというメモリ リークが発生します。ConstructorArgumentこれにより、そのターゲット オブジェクトが GC されるのを防ぎます。それが違いを生む場合、私は ContextPreservation 拡張機能も使用しています。(以下の完全なサンプル コードを参照してください)

「ToFactory()」バインドを削除して標準のファクトリ クラスを作成すると、機能します。

そして、デリゲート内のターゲット オブジェクトは正常に GC されます。

私が間違っていることはありますか、それとも Factory 拡張機能はこれらのより複雑な引数を処理するためのものではありませんか? を使用した場合.WithConstructorArgument、同じ結果が得られると思います。

編集: 必要なバインディングをすべて追加し、サンプル コードを書き直しました:

すべてのアセンブリをスキャンして、特定の属性を持つクラス（または抽象クラスColorTestから継承されたクラス）を探し、それらを自動的にColorTestにバインドする必要があります。次に、 ColorTestのすべての実装をインスタンス化して列挙する必要があります

アセンブリ1：

アセンブリ2：

アセンブリ3：

アセンブリ4：

例は、より複雑な問題の抽象化と単純化です。

Ninjectは、説明されているシナリオを処理するのに役立ちますか？はいの場合、どのように？

最新のNinject.Extensions.Wcf (3.0.0.5) を nuget から取得しましたが、

SelfHostの例で使用されている NinjectWcfConfiguration タイプはそのパッケージにありませんか?

Ninject、Ninject.Logging、Ninject.Extensions.NLog2を使用するシンプルなコンソールアプリがあり、すべて最新のnugetパッケージでビルドされています。

私のアプリは次のことを行います

StandardKernelそして、呼び出し時に内部からNullReference例外が発生しますGet<ILogger>()

ロギングを機能させるために必要な設定は他にありますか？

このコードを置き換えたい:

このようなもので：

IBindingGenerator を作成しようとしましたが、T から ITaskFactory<T> を取得しようとしたときに立ち往生しました。