問題タブ [dependency-injection]

WindowsWorkflowFoundationの内部を理解しようとしています。そのため、いくつかのソフトウェアコンポーネントがあり、条件ベースのシーケンシャルワークフローまたはステートマシンワークフローのワークフローの形でそれらを絡み合わせています。今、私は（ここでは間違っているかもしれませんが）IoC +依存性注入（UnityまたはSpring.net経由）には同じことが当てはまらないと考えています。いつ何を使うの？私も正しいと思いますか？

最も簡単に開始できる IoC コンテナーはどれか。これはおそらく、どれが最もわかりやすいドキュメントを持っているかに相当します。機能の数はあまり気にしません。

依存性注入を使用して、テスト対象のクラス外のコードにモックを提供しています。テストしたいメソッドで使用されるAuthProvider、ConfigurationManagerなどをモックアウトする必要があるため、同じコードを何度も何度も書いていることに気づきました。メソッドには分岐 (if-then-else) が含まれているため、メソッドのすべての実行パスをテストするために複数のテストを用意しています。各モックを数回 (各テスト メソッドで 1 回) インスタンス化していますが、これは間違っているのでしょうか? また、すべてのメソッドで AuthProvider.Authenticate() などの呼び出しが呼び出されるため、明らかにほとんどがコピーアンドペーストであるモックとプリセット応答に期待しています。

各メソッドでモック リポジトリをセットアップし、各メソッドの最後でモック リポジトリを検証します。これらのモックを作成し、期待値と戻り値を設定するためのある種のファクトリを用意する必要がありますか?

モックの実装には RhinoMocks を使用しています。

Microsoft Unity では、既存の XML 構成からコンテナーを構成できますが、逆の方法はありますか? 初期化されたコンテナーから、対応する XML 構成をエクスポートしますか?

私のプロファイラー レポートでは、依存性注入を使用したモックベースのテストの結果がますます見られます。依存関係の多くは静的でしたが、メソッドを分離してテストしたいので、次の例のようにインスタンス メンバーに変更されます。

次に、ほとんどの場合、依存関係には他の依存関係などがあります。これにより、テスト外でメソッド呼び出しが行われるたびに、(ほとんどが「静的」) オブジェクトのツリーがインスタンス化されます。各オブジェクトは非常に小さい (ほんの数個のポインター) ですが、ツリー効果により、これがますますパフォーマンス ヒットに変わります。

私たちはそれについて何ができますか？

Dependency Injection に関する多くの記事を読み、多くのビデオを見てきましたが、まだ理解できません。誰かがそれを説明するための良い例えを持っていますか?

アジャイルの秋スクリーンキャストの最初の部分を見ましたが、まだ少し混乱していました。

2 つの Bean を宣言し、Spring 依存性注入を使用してそれらをインスタンス化したいですか?

しかし、Spring は「現在作成中の FactoryBean が getObject から null を返しました」という例外をスローします。

ここで相互に依存する Bean の配線が機能しないのはなぜですか? どこでも遅延プロパティバインディングを指定する必要がありますか?

オブジェクトプロパティ値の差分を拡張していますが、オブジェクトのプロパティが多すぎる場合は、すべてを差分したくない場合があることに気付きました。だから私は思いついた

差分で無視するプロパティをマークできるようにします。ただし、[IgnorePropertyDiff]でドメインオブジェクトを汚染したくありません。

私の質問は、Ninjectや他のIoCのようなIoCを使用して[IgnorePropertyDiff]を動的に注入することは可能ですか？私は完全に馬鹿げているように聞こえる場合は、私は中級レベルのc＃開発者にすぎないので、私を処刑してください。前もって感謝します。

フレームワークの統合から BasePage と BaseMaster を使用して、Web アプリケーションで Ninject を使用しています。私がやりたいのは、オブジェクトを注入し、セッションごとに新しいインスタンスを作成することです。OnePerRequest の動作を見てきましたが、近いですが、完全ではありません。私がやっていることは多くの計算を実行することであり、それらの変数はページに挿入されるオブジェクトに保持されます。ポストバックのためにそれらのオブジェクトを保持する必要がありますが、ユーザーがサイトに「アクセス」するたびにオブジェクトの新しいインスタンスが必要です。私の最初の考えは、ポストバック間の値を保存するために何らかの方法で Asp.net セッション オブジェクトを使用することでした。これは、Ninject の前に行う方法です (オブジェクトをセッションに保存するだけです。できれば正しい方法です。他の提案も受け付けています。シングルトンを使用することを考えましたが、各ユーザーはオブジェクトの独自のコピーが必要になります。そうしないと、お互いの計算を踏むことになります。

それが明確であることを願っています。既存の動作を使用するか、独自の動作を作成するかについてアドバイスをいただければ幸いです。おそらく、アプリケーション キャッシュまたは組み込みの ASP.NET キャッシュを使用するとうまくいく可能性があります。

ありがとうございました

ジョシュ

依存性注入フレームワーク (春のアノテーション) への最新の追加により、DI 管理コンポーネントを作成するための限界コストは、いくつかの重要な新しいしきい値に達したようです。以前は、Spring に関連するオーバーヘッド (大量の XML と追加の間接参照) がありましたが、依存性注入は、多くのパターンが進むところに行き始めたようです。彼らはボンネットの下に入り、「消えます」。

この結果、多数のコンポーネントに関連する概念的なオーバーヘッドが許容できるようになります。ほとんどのクラスが単一の public メソッドのみを公開するシステムを作成し、これらの断片を狂ったように集約するだけでシステム全体を構築できることは議論の余地があります。私たちの場合、いくつかのことが与えられています。アプリケーションのユーザー インターフェイスには、最上位のサービスを形成するいくつかの機能要件があります。そして、バックエンドシステムが下部を制御します。しかし、これら2つの間では、すべてが手に入る.

私たちの絶え間ない議論は、実際にはなぜ物事をクラスにグループ化するのか、そして原則はどうあるべきかということです。いくつかのことは確かです。ファサードのパターンは死んで埋もれています。複数の無関係な機能を含むサービスも、分割される傾向があります。「無関係な機能」は、私がこれまで行ってきたよりもはるかに厳密な意味で解釈されます。

私たちのチームでは、ここで 2 つの一般的な考え方があります。実装の依存関係によってグループ化が制限されます。単一のクラスの機能は、注入されたすべての依存関係のクライアントであることが望ましいです。私たちはDDDプロジェクトであり、他の部分はドメインがグループ化を制限していると考えています（CustomerServiceまたはより細かいCustomerProductService、CustomerOrderService）-注入された依存関係の正規化された使用は重要ではありません.

では、疎結合の DI ユニバースでは、なぜロジックをクラスにグループ化するのでしょうか?

編集: duffymo は、これがプログラミングの関数型スタイルに移行している可能性があると指摘しています。これは状態の問題を引き起こします。関連するアプリケーションの状態の (小さな) 部分を表す "状態" オブジェクトがかなりあります。この状態を正当に必要とするサービスにこれらを挿入します。(通常のドメイン オブジェクトの代わりに「状態」オブジェクトを使用する理由は、Spring が不特定の時間にこれらを構築するためです。これは、Spring がドメイン オブジェクトの実際の作成を管理できるようにするためのわずかな回避策または代替ソリューションであると考えています。より良い解決策があるかもしれません。ここ）。

したがって、たとえば、OrderSystemAccessControlState を必要とするサービスはすべてこれを注入することができ、このデータの範囲はコンシューマーにはすぐにはわかりません。セキュリティ関連の状態の一部は、通常、さまざまなレベルで使用されますが、その間のレベルではまったく見えません。これは機能原則に根本的に違反していると本当に思います。オブジェクト指向の観点からこの概念に適応するのにも苦労しましたが、注入された状態が正確で強く型付けされている限り、その必要性は正当であり、ユースケースは適切です。