問題タブ [dependency-injection]

.NET 1.1 をサポートする制御の反転 (IoC) コンテナーはどれですか?

注: 以下の例は C# ですが、この問題は特定の言語に固有のものではありません。

そのため、 S# Architectureのバリアントを使用してオブジェクト ドメインを構築しています。なじみのない人のために、また読む時間を節約するために、永続化レイヤーとの間のロードを担当するドメイン オブジェクトごとに Data Access Object Interface を用意するという単純な考え方があります。特定のオブジェクトをロード/保存するために必要なすべてのものは、そのオブジェクトのデータ アクセス インターフェイスを依存関係として受け入れます。したがって、たとえば、製品が必要に応じて購入した顧客を遅延ロードする次のようにすることができます。

2 つのオブジェクトが相互にロードできる必要がある状況に到達するまでは、これで問題ありません。たとえば、上記のように、製品がその顧客を遅延読み込みできる必要があるだけでなく、顧客が自分の製品のリストを取得できる必要がある多対 1 の関係です。

これは非常に一般的な状況であることは知っていますが、私はこれに比較的慣れていません。私のつまずきは、データ アクセス オブジェクトを実装するときに何をすべきかということです。Customer は IProductDao に依存しているため、CustomerDao の実装も必要ですが、逆もまた真であり、ProductDao は ICustomerDao に依存する必要があります。

そして、ここに問題があります。IProductDao なしで CustomerDao をインスタンス化することはできません。制御コンテナー (Castle Windsor) の反転は、循環依存関係にヒットし、チョークします。

私は、DAOオブジェクト自体を遅延ロードすることを含む当面の解決策を思いつきました（これを回答として投稿します）が、私はそれが好きではありません。この問題に対する定評のある解決策は何ですか?

編集:上記は私が実際に使用しているアーキテクチャを簡略化したものであり、誰かが実際にオブジェクトに DAO を渡すことをお勧めしていません。私が実際に行っていることに近いより良い実装は、実際のオブジェクトが非常に単純で、上記が実際には適切なフィールドを継承してオーバーライドするプロキシ オブジェクトである NHibernate の動作に似ています。

私は依存性注入が初めてなので、次のシナリオをどのように処理するのだろうかと思っています。次のようなものがあります。

Web アプリケーションの場合、各リクエストは異なる DatabaseContext を構築して、異なるデータベースを指すことができます。Windows フォームの場合、現在の DatabaseContext を変更できます。di フレームワークは、変更可能な依存関係をどのように処理しますか? IDataAccess を要求すると、常に適切な/現在の DatabaseContext が含まれるようになります。

スタック オーバーフローに関するリンクを見つけたので、Miško Heveyの著書は非常に魅力的な読み物であることがわかりました。とても良いので、以前は自分がうまくやっていると思っていたことに新しいアプローチが見られるようになりました.

彼は主に、依存性注入、自動化されたユニット テスト、優れた設計について語っています。

彼が提唱する優れた実践の多くは、プログラムで検出できるものです。そのため、 Google Testability Explorerを検出するプログラムがあります。

私の質問は次のとおりです。

• Java ベースの Google Testability Explorer に相当する C# はありますか?
• もしそうなら、どれが最高ですか？

私はいくつかの Ruby 依存性注入ライブラリを見てきました。特に、 NeedleとCoplandをチェックしました 。それらはかなり前から存在していますが、あまり使用されていません。

これら 2 つのライブラリを使用することの長所と短所は何ですか? Merb / Datamapper's Hookなど、多くのライブラリ / フレームワークがこれら 2 つのライブラリをうまく利用できるようです。

主にユニットのテスト容易性を向上させるために、WPFアプリケーションで依存性注入の使用を開始したいと思います。私のアプリは主にMV-VMパターンに沿って構築されています。私はIoCコンテナのAutofacを見ていますが、それはこの議論にとってそれほど重要ではないと思います。

App.xaml.csでコンテナーを作成して解決できるため、開始ウィンドウにサービスを挿入するのは簡単なようです。

私が苦労しているのは、ViewModelsとServicesをユーザーコントロールにDIする方法です。ユーザーコントロールはXAMLマークアップを介してインスタンス化されるため、ユーザーコントロールを使用する機会はありませんResolve()。

私が考えることができる最善の方法は、コンテナーをシングルトンに配置し、ユーザーコントロールにグローバルコンテナーからViewModelを解決させることです。これは、コンポーネントがServiceLocatorに依存している必要があるため、せいぜい中途半端な解決策のように感じます。

WPFで完全なIoCは可能ですか？

[編集]-Prismが提案されていますが、Prismを評価することさえ大きな投資のようです。もっと小さいものが欲しいです。

[編集]これが私が止められたコードフラグメントです

ASP.NET サイト (例: ASP.NET MVC サイト) を実行するときに、テスト永続化レイヤーを作成するためのベスト プラクティスは何ですか?

私が見た多くの例では、単体テスト プロジェクトで Moq (または別のモッキング フレームワーク) を使用していますが、永続化レイヤーを moq アウトして、Web サイトにデータなどを表示するようにしたいのですが、それはデータベースからのものではありません。それを最後にしたい。私が見たすべてのモックは、単体テストにしか存在しません。

迅速かつ迅速な開発のために永続化レイヤーを偽造 (スタブ?) したい場合、人々はどのようなプラクティスを実行しますか? 私はそれを処理するために Dependency Injection を使用し、永続化レイヤーにハードコードされた結果をいくつか持っています (これは本当に手作業で退屈です)。

他の人は何をしていますか？例とリンクは素晴らしいでしょう:)

アップデート

ちょっとした更新: これまでのところ、各クラスがインターフェイスを実装する偽のリポジトリと SQL リポジトリを使用することで、かなりの距離を稼いでいます。次に、DI (私は StructureMap を使用しています) を使用して、偽のリポジトリと SQL リポジトリを切り替えることができます。これまでのところ、うまく機能しています:)

（これを編集していたときから、ほぼ11か月前にこの質問をしたと思うと恐ろしいです！）

IOC をコンソール アプリケーションに組み込むための優れたソリューションを思いつく人はいますか?

現時点では、次のメソッドで静的クラスを使用しています。

エクスペリエンスをシームレスにしたいのですが、コンソール アプリケーションからこれを実現する方法が思いつきません。

私たちが持っているとしましょう

そしてそれを消費するクラス

およびデフォルトの実装:

このコンストラクターを導入することは役に立ちますか、それとも有害ですか?

これは一般的な質問です。つまり、タイムスタンプは興味深い部分ではありません。

私はこれについてかなりの検索を行いましたが、まとまりのあるものを見つけることができませんでした. 私は比較的新しい開発者で、最初の専門的な開発職に就いたばかりです。基礎の領域でも学ぶべきことがたくさんあることを知っています。PodCast を聞いたり、ブログや論文を読んだりすることに基づいています。ソフトウェアを設計および構築するときに、関心の分離、IOC、依存性注入を念頭に置くことが正しいことのように思われることを理解するようになりました。私は概念を非常に高いレベルで理解しており、マイニングでこれを使ってできる限り取り組みたいと思っています。

だから、ここに摩擦があります。どうやってこのようにデザインするのですか？私は、非常に緊密に結合され、文書化が非常に不十分で、一般的にソフトウェアの保守が容易ではない Web ベースの製品を継承したチームで働いています。Evryone は、このカップルの一部を削除するというアイデアを気に入っているようです。彼らは、自動化されたテストを開発するというアイデアを気に入っています (私が読んだ限りでは、疎結合コンポーネントの方が簡単です)。誰もそれを行う方法を知らないようです。試してみたいのですが、アドバイスが必要です。私が見つけたものはすべて、常にこのことについて非常に高いレベルで話しているように見えます。逆に、全体のほんの一部に焦点を当てているようです. 本、一連のチュートリアル、ビデオ、または現実世界の例を取り上げてこれらの原則を適用する方法を示す何かについてのガイダンスが欲しい. 理想的には、

私が見つけた包括的なトレーニング資料のほとんどが、初​​心者がその日から良い実践を適用できるようにこのトピックを議論していないことに少し不満を感じています. 1。

お時間をいただきありがとうございます。

スティーブ