問題タブ [dependency-injection]

POCO ドメイン オブジェクトの依存関係を解決するように NHibernate に指示する方法を知りたいです。

CalculateOrderTax などのメソッドは、ドメイン固有のビジネス ルールをエンコードするため、Domain オブジェクトに含める必要があることがわかりました。しかし、それらを 2 つ取得すると、SRP に違反します。

これらのメソッドを Strategy クラスに抽出することは問題ありませんが、NHibernate にそれらをロードさせるにはどうすればよいでしょうか。

オブジェクトを上位レイヤーに渡す前に、リポジトリ内のオブジェクトのリストをループして get/set ベースの依存性注入を行うのは、良い解決策とは思えません。

また、現在、依存関係の注入にキャッスル ウィンザーも使用しています。

ユーザー、セキュリティ/ロールのデータベースを使用し、コンテンツを保存する Web アプリケーションを構築しています。

テストを実行するには、データベースが適切に初期化されていることを確認する必要があるため、単体テストの道を歩み始めるのは少し気が遠くなるような気がします。

この点で役立つ一般的な慣行は何ですか?

つまり、開発/テスト中にユーザーを削除する可能性がありますが、テストに合格するには、そのユーザーがプロファイル、セキュリティ設定などとともにデータベースに存在する必要があります。

セットアップ スクリプト、データベースを再作成するための何かなどを作成できることはわかっています。

テストを維持し、データベースが同期していることを確認するためにすべての時間を費やしたくありません

それとも単体テスト/TDD のコストですか?

IOCでは何をしResolveAllますか?? 公式の答えは「このタイプに一致するすべての有効なコンポーネントを解決する」であることを知っています。これは、特定のインターフェイスを実装する任意のクラスを返すということですか?

同じインターフェースを介して 1 対多のバックエンド システムに接続するプロジェクトが近づいています。それを IBacksideProvider と呼びましょう。

Unity を使用して、実行時にこれらのプロバイダーを挿入したいと考えています。問題は、1...n 個のバックエンド システムについて話しているため、IBacksideProvider の 1...n 個の実装を登録する必要があることです。Unity は、そのままではこれをサポートしていません。

ただし、このブログ投稿は、それが可能であることを示唆しています。誰かがこれを行ったことがあるか、またはこれを行うために Unity を操作する方法を考えているかどうか疑問に思っています。ティア。

これは、依存性注入を扱っていたMiško Hevery のGoogle トークの 1 つのコメントで私が尋ねた質問でもありますが、コメントに埋もれてしまいました。

依存関係を一緒に配線するファクトリー/ビルダーのステップがC++でどのように機能するのだろうか。

つまり、B に依存するクラス A があります。ビルダーは B をヒープに割り当て、A のコンストラクターで B にポインターを渡し、同時にヒープに割り当て、A へのポインターを返します。

後片付けは誰がするの？完成後はビルダーに片付けてもらってもいいですか？話の中で、ビルダーは同じ寿命を持つことが期待されるオブジェクトをセットアップするか、少なくとも依存関係の寿命が長くなる必要があると述べているため、これは正しい方法のようです (私もそれについて質問があります)。コードでの意味：

ここで、注入先のオブジェクトの有効期間よりも長く続くことが予想される依存関係がある場合 (ClassC がその依存関係であるとします)、ビルド メソッドを次のように変更する必要があることを理解しています。

あなたの好みのアプローチは何ですか？

IOrderDataLoader の多くの実装を持つ winforms applicatoin があります。他のチームは、IOrderDataLoader の独自の新しい実装を構築し始めています。そこで、DLL のディレクトリを調べて、リフレクションを使用して IOrderDataLoader を実装するすべてのクラスをロードするようにアプリを切り替えました。このようにして、他のグループが独自に dll を展開し、メイン アプリがそれらをオンデマンドでロードできます。

問題は、独自の展開に移行しようとしている内部プロジェクトとしての実装の 1 つに、多くの依存関係があることです。これを分解して、すべての依存関係をロードするにはどうすればよいですか? 他のすべてのデータローダーには空のコンストラクターがあるため、単純にループします。.

私は依存性注入を見ています。利点はわかりますが、それが作成する構文に問題があります。私はこの例を持っています

書きたくないのが問題

私は書き続けるだろう

最初の選択肢が不自然に感じるからです。製品を取得するために BusinessProduct が「依存」するものを知りたくありません。また、コードが読みにくくなると感じています。

オブジェクトを作成するための元の構文を維持したいが、単体テスト時に依存関係を偽造できるようにしたいので、このアプローチに代わるものはありますか?

私は c# でコーディングしていますが、他の言語からの代替も大歓迎です

Application_Start メソッドで使用される Autofac モジュールに次のコードがあります。

リポジトリのコンストラクターは、ISession を引数として受け取ります。しかし、明示的に HttpRequestScoped にするように要求したにもかかわらず、アプリケーション全体に対して 1 つのセッションになってしまいます。

ContainerDisposal HTTP モジュールを構成しました。

ドキュメントによると、ネストされたコンテナーを作成する必要がありますが、Autofac に依存関係を自動配線させています。

私は何をすべきか？

ありがとう！

私は、外部サービスのメッセージングが多いプロジェクトに取り組んでいます。少しだけ「双曲線」の方法で説明すると、システムが Flicker API、Facebook API、および Netflix API にメッセージを送信する必要があるアプリケーションになります。

切断されたシナリオ、ログの懸念事項、開発者の使いやすさ、構成などをサポートするために、ジェネリックと式ツリーを多用するアプローチを使用して実験しました。最終結果は次のようになります。

全体として、最終結果には満足していますが、テストと接続されていないシナリオに関して、どこかで間違いを犯したか、設計原則を見落としているように感じます。

テスト中に、自動、ユニット、または人間ベースのいずれであっても、最初は DI を使用して「ライブ モード」で正しいアクションを実行するオブジェクト ファクトリを実装し、モックを使用して、何もしない無菌メッセンジャーのようなものを提供しました。テストモードの場合はすべて。

モックが純粋な TDD モードで使用されており、一種のダムオブジェクトとして使用されていないことについて、私は見たり読んだりしただけです。私が見たアプローチは、私が使用しているすべての API が依存している HTTP 通信機能をスタブ化またはモックアウトすることを中心に展開していました。

私の主な懸念は、私が接続すると予想されるすべての異なるサービスが、特定の HTTP 実装を置き換える多くの詳細な作業を行う必要があり、スタブアプローチを使用した場合、これらのサービスごとに 3 つのクラスがあることです。 ( IService、ConcreteService、StubService ) であり、新しいメソッドを実装したり何かを変更したりするときにそれらを維持することは、実際の PITA になります。

現在の実装では、モックを使用して「無菌モード」を無料で取得していますが、特定のテスト プリンシパルに準拠するためだけに余分なものを実装する必要はほとんどありません。

問題は、私が何か不足しているのでしょうか? より便利な方法でモックを使用して、設計原則に違反しましたか?

多くのフープを飛び越えることなく、多くの異なる外部サービスから無菌モードを取得する方法について、誰かアドバイスを提供できますか?

この質問は理にかなっていますか？

すべての答えをありがとう。

編集＃1：

元の質問では明確ではありませんでした。null またはモック オブジェクトは、開発/デバッグ/テスト環境でのみ使用されます。本番環境では、これらのメッセージを送信するコードが実際の実装になります。

この問題にはさまざまな解決策があるようで、それぞれを調査する予定なので、全員に投票しました。

この質問はまだ回答されていないと考えてください。できるだけ多くのアドバイスをいただければ幸いです。

Hibernateから取得したJPAエンティティにランタイム依存関係を注入する方法に関する提案を探しています。私の問題は本質的にこれです：

Transactionオブジェクトにはいくつかの異なるサブクラスがあります。各Transactionサブクラスは、実行時の動作が異なり、環境とは異なる依存関係のセットを必要とします。これらのトランザクションオブジェクトはHibernateによってJPAエンティティとして管理されるため、依存性注入にGuiceを効果的に使用して、アプリケーションの他の部分のようにインスタンスに環境依存性を設定することはできません。

この問題を回避するために、次のように、Visitorパターンにいくぶん似たアプローチを採用しました。

トランザクションライフサイクルのさまざまな部分に対して、Transactorのさまざまな実装があります。これらは、Guiceを使用して、トランザクションを処理するコンテキストに依存性注入することができます。ここでは、単に次のように呼び出します。

このアプローチについて私が気に入らないのは、（1）すべてのタイプのトランザクションが各ライフサイクルフェーズで実行可能である必要はありませんが、すべてのTransactorはすべてのトランザクションサブクラスに対してexecute（）メソッドを実装する必要があり、（2）注入された依存関係は基本的にありません複数のトランザクションタイプを処理するために使用されます。

基本的に、私のTransactorインターフェースと実装には、無関係な多くのクラッドが一緒にまとめられています。理想的には、トランザクションオブジェクト自体にexecute（）メソッドを設定するだけですが、呼び出し元のコードがトランザクションのタイプや必要な依存関係について知る必要はありません。また、Transactionオブジェクトの具体的なメソッドである場合、execute（）メソッドを簡単にモックアウトできないため、テストが難しくなる可能性があります。Transactorインターフェースを使用すると、必要に応じて簡単にモックアウトできます。

誰もがこの問題にタイプセーフな方法で対処する方法を提案できますか？トランザクターでほとんど無関係な動作の束が一緒にグロミングされることはありませんが、テスト容易性を維持し、依存性注入を可能にしますか？