問題タブ [ninject]

通常、私はこれを行います：

UserDao は IUserDao の具体的な実装です。

だから今、私のコードは散らばっています：

実装を交換したい場合は、DBFactory に移動し、別の実装を呼び出すようにコードを変更する必要があります。

NINject を使用する場合、アプリケーションの起動時または構成ファイルを介して特定の実装をバインドします。（または特定のパラメータなどに基づいてバインドします）。

それだけですか？それとももっとありますか？

（ここでどのように役立つかを知りたいかどうかを尋ねている理由：注文マネージャークラスの設計を支援する）

ASP.NET MVC Web アプリで Ninject 2 を使用しています。すべての依存関係は、スタック (コントローラー -> サービス -> リポジトリー) で適切に処理されます。ただし、サービス プロジェクトには、アプリの起動時に挿入したい「チェーン」にないクラスがいくつかあります。Ninject にそれらを認識させるにはどうすればよいですか? 属性を持つパブリック プロパティがあり[Inject]ますが、アプリを実行すると null になります。私は何が欠けていますか？

ここに私の MvcApplication クラスがあります:

正しいバインディングが存在することを確認するために、両方のモジュールを再確認しました。

モジュールからのサンプル:

そこで私はこの新しいプロジェクトを開始し、私が読んでいたすべての新しい設計原則を取り入れようとしました。つまり、物事をゆるく結合し、テスト可能にし、いくつかのパターンに従うようにしました。

そのため、クラスコンストラクターに多くのファクトリ/マネージャーを渡さなければならないという問題に遭遇しました。これにより、依存関係の注入が発生しました。

したがって、私がninjectを使用する場合、私が理解していることから、特定の実装をクラスにバインドします。

では、舞台裏で何が起こっているのでしょうか？

NInjectは、SomeClassをインスタンス化するたびに、構成ファイルで定義した実装をバインドしますか？

すなわち

そうです：

そしてninjectはします：

正しい？

現在、サービス層とデータ アクセス層に分割されているアプリケーションがあります (MVC 層が進行中です)。クラスで必要なボイラープレート Ninject コードの量を減らそうとしています。

私の最初のアイデアは、UserService と UserDAO によって拡張される各ビジネス オブジェクト タイプ (つまり、UserBase) の基本クラスでした。残念ながら、それでは他のクラス (つまり、すべての Service 実装によって拡張される AbstractService クラス、AbstractDAO クラスなど) を拡張できなくなります。

私の 2 番目のアイデアは、渡されたさまざまな IModule 実装の IKernel を返す単純なファクトリでした。残念ながら、各クラスには IKernel メンバー変数が必要でしたが、これで問題が解決し、AbstractService と AbstractDAO を作成できるようになりました。

Ninject の使用を最適化するための他のアイデアはありますか?

IoCコンテナとしてNinjectを使用して動的インジェクションを処理するフレームワーク拡張機能に取り組んでいますが、これを実現する方法を見つけるのに問題があります。

IModule(s)私のフレームワークには、MVCやWebFormsなどで簡単に使用できるように渡すことが期待されています。したがって、クラスは次のように構成されています。

これは問題ありません。単体テストでインスタンスを作成し、の基本的な実装に合格することができます（テストに推奨されていると思われるIModuleビルドを使用）。InlineModule

問題は、注入する必要のあるタイプがわかるのは実行時までではなく、次のようなメソッドで、拡張しているフレームワークを介して要求されることです。

そして、これが私が困惑しているところです、私はチェックするための最良の方法がわかりません->作成（必要な場合）->戻る、私はこれまでにこれを持っています：

これにより、コンポーネントコレクションに追加されますが、インスタンスが作成されたかどうか、またはインスタンスを作成しての引数を渡す方法がわかりません.ctor。

私はこれを正しい方法で行っていますか、それともNinjectはそのように使用されることさえ意図されていませんか？

単純なPOCOを目的とした単純なクラスがあります。データを保持するだけです。1つの例外を除いて：メモのコレクションが含まれています。このコレクションを遅延ロードして、それらを必要としないページ上のメモをフェッチする必要がないようにします。このためのスタブはこれです：

さて、ここからどうやって進めたらいいのかしら。これはASP.netMVCアプリケーションであり、依存性注入を使用して、IRepositoriesを必要とするクラス（コントローラーなど）に注入します。ただし、このクラスは非常に単純なDTOであると想定されているため、INoteRepositoryを挿入することには消極的です。これは、呼び出し元が遅延読み込みであるという事実を心配したり気にしたりする必要がないためです。

そのため、INoteRepositoryを保持する別のクラスをモデルに含めることを考えています。

これはもちろん機能しますが、これが正しいアーキテクチャであるかどうか疑問に思います。単純なDTOClassを別のデータアクセスクラスに結合し、場合によってはDIメカニズムにも結合します（Notesのゲッターでデータアクセスクラスのインスタンスを作成する必要があるため）。

別の方法でやりますか？私がすでにNinjectを使用していることを念頭に置いて、これを行うためのより良い方法はありますか？

ロジックが含まれているため、これはPOCOまたはDTOではなくなったと思いますが、問題ありません。外部の呼び出し元にはPOCOのように見せたいので、このクラスや他のクラスに「GetNotesForProject」のようなメソッドではなく、プロパティ「Notes」を設定したいと思います。

私の現在のソリューションは本当に醜いです。MvcApplicationからNinjectカーネルを取得し、それを使用してコンストラクターでINoteRepositoryを取得するProjectDataProviderクラスを起動し、INoteRepositoryを「DTO」クラスのどこかに配置する必要がないようにする必要があります。 ：

編集：報奨金を開きました。「POCO」と「DTO」の用語は無視して、それに応じてリファクタリングします。つまり、これは次のことです。このような状況で遅延読み込みコードはどのように見えるべきでしょうか。また、INoteRepositoryをMyDTOClassに渡さないようにすることはできますか。

Ninject のような DI フレームワークが基本を超えてどのように動くかを「理解」するには、もう少し助けが必要です。

Ninject サンプルを取得します。

DI フレームワーク (つまり、上記の [Inject] 参照) がなければ、参照クラスは次のようになります。

...すべてを新しくしている場所。はい、Samurai で依存関係を削除しましたが、チェーンの 1 ステップ上の依存関係を取得しました。単純。

Ninject を使用すると、次の方法ですべてを新しくする必要がなくなります。

ただし、これは私の混乱の領域です: 適用可能なカーネルとモジュール (つまり .IoC.TypeResolver.Get<>()) を効率的に更新するために何らかのサービス ロケーターを作成せずに、どこでもカーネルを新しくする必要はありません（サービスロケーターはどこでも参照しますか？）、そしてb）さらに重要なことに、独自の依存関係を持つ依存関係を持つ大きな長いチェーンがある場合、インジェクションをずっと渡すという極端な方法を取ります私が確信しているのは、深刻なアンチパターンです (友人はそれを「ホットポテト依存性注入」アンチパターンと呼んでいました)。

言い換えれば、DI フレームワークの魔法の 1 つは、依存関係をチェーンのずっと上に挿入し続ける必要がないことだと思いました (つまり、コンストラクターに 10 個のパラメーターを含む最初の参照で、いずれも関係がありません)。チェーンに沿ってはるかに遠くまで何か）-依存関係がチェーンの上下に継続的に参照されたり、サービスロケーターの参照がいたるところに広がったりしないように、私の混乱に対する魔法または解決策はどこにありますか.

私にとってさらに混乱しているのは、DIフレームワークを使用している場合、参照されるクラスが通常コンストラクターに配置されるIList(つまり、新しいReferencedClass(myList))を必要とするシナリオに対処する最良の方法は何ですか?文字列データベース接続文字列のような単純なケースでは、飛びません。プロパティを作成して、新規作成/DI フレームワーク サービスの検索後に設定するだけですか? いえ

全体として、これは受け取った後に恥ずかしくなる可能性が高い投稿だと思いますが、今のところ、最善のアプローチを決定しようとして何度も壁に頭をぶつけてしまいました.

Spring.Netの組み込みIoCコンテナをNinjectに置き換えることが可能かどうか知りたいです。私たちは他のプロジェクトでIoCのチームでNinjectを使用しているので、可能であればそのコンテナーを引き続き使用したいと思います。

これは可能ですか？誰かがNinject-Spring.Netアダプターを書いたことがありますか？

編集

Spring.Netパッケージの多くの部分（データアクセス、トランザクションなど）は好きですが、依存性注入コンテナはあまり好きではありません。それをNinjectに置き換えたい

ありがとう

IIS 7.0 の Windows Activation Service を使用してアクティブ化される MSMQ Binding を使用する一方向の WCF サービスがあります。

私は NInject の大ファンなので、WCF 用の NInject 拡張機能を使用してきました。これは、典型的な HTTP WCF サービスではうまく機能します。

ただし、WAS アクティブ化サービスには HTTP パイプラインがないため、System.Web.HttpContext.Current が null であるため、型をバインドするときに InRequestScope を使用できません。WAS を使用するときに、必要なものを提供してくれる代替手段を見つけるのに苦労しています。AspCompatibility モード属性もこのモードでは機能しません。

InThreadScope が機能する可能性があると思いましたが、サービスは実行されるスレッドとは別のスレッドで作成されます。

したがって、基本的には、WCF+WAS の HttpContext に相当するオブジェクトを要求レベルでスコープする必要があります。この世界に同じように機能する静的なオブジェクトはありますか、それとも私が一緒にハッキングできる何かについて何かアイデアを持っている人はいますか?

Ninject のサイトにはバージョン 1.0 しかありません

ninject.framework.mvc ライブラリを含むものはどこで入手できますか?