問題タブ [constructor-injection]

依存性注入のためにNinjectからTinyIoCに変更したばかりで、コンストラクター注入に問題があります。

私はそれをこのスニペットまで単純化することができました：

これにより、TinyIoCResolutionExceptionが次のようにスローされます。

その例外の中には、一連の内部例外があります。

コンストラクターインジェクションの使用方法に何か問題がありますか？私は私が呼ぶことができることに気づきます

それは確かに機能しますが、結果はBarのグローバルインスタンスであり、私が求めているものではありません。

何か案は？

ASP.NET MVC3 アプリケーションには Unity を使用しています。構成は web.config ファイルでのみ行われます。シングルトンを使用している以下の例を参照してください。コンストラクタインジェクションを使用しています。私たちのクラスの 99% では、シングルトンの有効期間プロパティを使用していません。パフォーマンスを調べたところ、同じリクエストに対して同じクラスの複数のインスタンスが複数回構築されていることがわかりました。リクエストごとに 3000 個のオブジェクトを生成するのではなく、約 200 個のオブジェクトに減らすことができることに気付きました。もっと大きな設計上の問題があるかもしれませんが、それはまた別の機会に。シングルトンを使用するユニティ クラス構成のかなりの部分を作成することを検討しています。

質問:

1. ライフタイム タイプをシングルトンにマークする場合、そのインスタンスは特定のユーザーまたはすべてのユーザー ベースに対してのみ共有されますか?
2. これらをシングルトンとしてマークすると、ユーザーが一度に複数のリクエストを実行する際の問題を回避するために、メソッドの同期をセットアップする必要がありますか?
3. 他に知っておくべきことはありますか？

コンストラクターのパラメーターとして文字列を必要とするクラスがありますが、このパラメーターは呼び出し元のコードによって決定されます。同時に、このクラスの存続期間は HTTP 要求ごとに関連付ける必要があります。そこで、カスタムの PerWebRequestTimelineManager を作成し、それを構成ファイルのターゲット タイプに使用しました。しかし、コンストラクター内の文字列は動的に決定する必要があるため、構成ファイルを介して ConstructorInjection を使用することはできません。抽象ファクトリを使用して動的な依存関係の問題を解決できますが、実装についてはよくわかりません。以下のコードを確認して、アプローチを検証できますか。具体的には、RegisterType と Resolve の呼び出しは少し場違いに見えますが、アプリケーション全体での連続する Resolve 呼び出しは同じインスタンスを取得できます。

構成ファイルの関連部分:

別の質問があります。コードを使用して依存関係を構成および注入する上記の方法が正しい場合、構成エントリは必要ないと思います。適切なオーバーロードをいつでも使用して、カスタム ライフタイム マネージャーをプッシュできます。場合によっては、構成ファイルのみを使用して同じことを達成したいのですが、ソリューションをどのようにコーディングすればよいですか?

したがって、ペイントで描画できると仮定しましょう。

AオブジェクトBに依存し、インスタンス化さCれるがC、 のインスタンスにも依存するクラスがありB、 のこのインスタンスをBに渡すものと同じにしたいとしますA。どうすればこれを達成できますか?

さて、あなたもおそらくそれをまったく理解していませんでした。それでは、先に進んでコードに変換します。

DI がなければ、次のように解決します。

DI を使用してこのようなことをきれいに達成するにはどうすればよいでしょうか? 私が望むのは非常に簡単です。 と のB両方Cをインスタンス化するときに、 の同じインスタンスを使用しますA。

シングルトンや一時的なものではなく、Web リクエストごとのライフスタイルでこれが必要であることに言及するのを忘れていました。

私は、テストに適したコードを書くためのベスト プラクティスを見つけようとしていますが、より具体的には、オブジェクトの構築に関連するプラクティスを見つけようとしています。ブルーブックでは、エンティティや値オブジェクトなどの破損を回避するために、オブジェクトを作成するときに不変条件を適用する必要があることを発見しました。これに従うと、次のようなコードを書くことになります。

まあ、これは一見良さそうですよね？オブジェクトが作成されるたびにCar、オブジェクトが「有効」であることを確認できるように、必要なコントラクトを公開する安全なクラスを構築しているようです。

では、テスト主導の観点からこの例を見てみましょう。

テストに適したコードを作成したいのですが、オブジェクトを分離してテストできるようにするには、Carオブジェクトを作成するためだけに、依存関係ごとにスタブまたはダミー オブジェクトのモックを作成する必要があります。メソッドのように、これらの依存関係の 1 つだけを使用するStartEngineメソッド。Misko Hevery のテスト哲学に従って、コンストラクターに null 参照を渡すだけの Door または Wheel オブジェクトを気にしないことを明示的に指定するテストを書きたいと思いますが、null をチェックしているので、それを行うことはできません。

これはほんの小さなコードですが、実際のアプリケーションに直面すると、サブジェクトの依存関係を解決する必要があるため、テストを書くのはますます難しくなります。

Misko は、コード内で null チェックを悪用するべきではないと提案しています (これは Design By Contract に反します)。それを行うと、テストを書くのが苦痛になります。別の方法として、彼は次のように述べています。私たちのコードは、どこにでもヌルチェックがあるという理由だけで安全です。」

これについてどう思いますか？どのようにしますか？ベストプラクティスは何ですか？

Unityを試していますが、XAMLでビューモデルを宣言する際に問題が発生します。あなたは私を助けることができます？XAML：

コンストラクタ：

実行しようとすると、resolutionfailedexceptionが発生します。これは、ビューモデルに空のコンストラクターがある場合に機能しました。コンストラクターの挿入に問題があるようです。

次のようにモジュールをロードすると、次のようになります。

できます。

xamlでこれを行う可能性はありますか（私は個人的にはより良いと思います）？

ちなみに、私は主にWebサービスと通信するwpfを使用してアプリケーションを作成しています。どちらかと言えば、UnityまたはMEFのどちらを使用する必要がありますか？また、この2つの大きな違いは何ですか？

ありがとう、ラフィ

私のコンストラクターが純粋な引数からプロパティへのセッターである場合、クラスが適切に機能するために必要な他のコードをどこに置くべきかわかりません。

たとえば、JavaScript では、オブジェクトのイベントWindowMessageControllerを処理するプログラムをプログラミングしています。messagewindow

これを機能させるには、ハンドラーをどこかにアタッチする必要があります。

このようなものはどこに正しく属していますか?

1. コンストラクターで
2. .initialize() メソッドで - 一時的な結合を導入します
3. WindowMessageControllerFactory.create(applicableWindow) で-非常に中心的なコードのかなり離れた場所です。これは、そのような小さなクラスでも 2 つに分割されることを意味します。
4. コンポジションルート自体で-これを常に行うと、そのサイズが倍増します
5. このコードを使用して、コンストラクターというメソッドを 1 つだけ持つ他のクラス WindowMessageRouter で

編集

通常、このようなコントローラーのインスタンスはアプリ内に 1 つしかないため、このケースは特殊なようです。しかし、より一般化されたケースでは、何らかの DOM要素Buttonをラップするクラスのインスタンスを作成していた場合の答えは何でしょうか? <button />突然

はるかに便利なようです。

2つの簡単なクラスを作成しました。1つのクラスのコンストラクターには、@Autowiredという注釈が付けられます。別のクラスのオブジェクトを受け入れます。しかし、このコードは失敗します。

クラス：-1）SimpleBean.java

2）Inner.java

ApplicationConextを読み込もうとすると

次のエラーが発生します：-

SimpleBeanクラスに引数なしのコンストラクターを導入した場合。エラーは発生しません。しかし、これでは、SimpleBeanの事前入力されたオブジェクトは提供されません（<constructor-arg>を使用したXML構成の場合のように）。したがって、アノテーションを使用する場合、引数なしのコンストラクターが必須ですか？適切な方法は何ですか？

重複の可能性:
コンストラクターまたはプロパティ セッターによる依存性注入?

プロパティ注入がコンストラクター注入よりも利点があるかどうか、私は興味があります:

対

私のプロジェクトにはPageCache、RavenDBに保存されている次のエンティティがあります。

Castle Windsorを使用してIHtmlDocumentHelper、実行時に実装を注入しています。このメンバーは、PageCacheクラス内で定義されたメソッドで使用されます。簡単にするために、上記のスニペットから削除しました。

PageCacheコンストラクターを使用してオブジェクトを作成すると、すべてが正常に機能します。しかし、コードの他の場所で、PageCacheRavenDBからオブジェクトをロードし直します。

私の問題は、RavenDBから返されるオブジェクトにhtmlDocumentHelperメンバーが設定されておらず、PageCacheそれに依存するメソッドが使用できなくなっていることです。

つまり、RavenDBに格納されているドキュメントからオブジェクトをロードし直すと、コンストラクターを使用してオブジェクトをビルドしないため、コンストラクターの挿入によってプライベートメンバーが初期化されません。

私はここで何か間違ったことをしていますか？そのような問題をどのように解決しますか？

私は、以下のAyendeによって提案されたソリューションを使用することになりました。コメントで述べた循環依存の問題はDocumentStore、ウィンザーにを登録したときにのみ発生しましたUsingFactoryMethod()。DependsOn()Windsorを使用して、の内部で直接OnCreate()構成および初期化すると、この問題は奇妙に消えました。DocumentStoreRegister()

私のコンテナは現在、次のように初期化されています。

正常に動作しているように見えますが、メソッドcontainer.Resolve<CustomJsonConverter>()内から呼び出さなければならないのは不思議です。container.Register()

これは、依存関係を登録するための合法的なアプローチですか？