0

最近、Ninject 1.0 を使用する比較的大きなコントロール ライブラリを Ninject 2.0 に更新して、1.0 で発生したいくつかの問題を解決する必要がありました。アップデートはうまくいき、Ninject 2.0 の方がはるかに速いと思います。

ただし、将来この問題を回避するために、フィールドとプロパティを注入するための独自のインターフェイスを作成しました (これは、現在の Web アプリケーション内で使用したい IOC コンテナーのメソッドを本質的に呼び出します)。これで、私のコントロール ライブラリは特定の IOC コンテナーから独立し、将来その領域での変更が高速化されます。

私は他の誰かが同じことをしたのだろうかと思っていましたか？

達成したことに満足していますが、理想的には更新したいと思います。私のコントロールでは、これらの注入されたフィールドを頻繁に保護されたものとして作成し、そのコントロールのコンストラクターに設定します。

IBlogService _blogService = null;
IEmailService _emailService = null;

public Templates_BlogTemplate()
{
    Inject(ref _blogService);
    Inject(ref _emailService);
}

上記の問題は、実際にプロパティを設定するには、すべてのオブジェクトで「ref」を使用する必要があり、プロパティでそれを直接使用できないことです。

私はこれらの線に沿って何かをしたいのですが、それが可能だとは思いません。

IBlogService _blogService = null;
IEmailService _emailService = null;

public Templates_BlogTemplate()
{
    Inject(_blogService, _emailService);
}

コードをすっきりさせる方法や、よりクリーンな方法で動作させる方法について何かアイデアを持っている人はいますか? また、属性を避けたいので、開発者はコントロール内の特定のポイントで変数を挿入することを決定する必要があります。

すべての考えや感情は大歓迎です。

ありがとう

4

2 に答える 2

1

プロパティの注入をサポートし、依存関係を「this」に注入します。

私の場合、StructureMap.BuildUp(this) を呼び出す基本クラスがあり、ユーザー コントロールには次のようなプロパティがあります。

public IBlogService _blogService{get;set;}
public IEmailService _emailService{get;set;}

私が持っている構造マップに固有の唯一の行は、基本クラスにあります。ninject でこれを実行できる場合は、コントロール インスタンスを渡すコードを呼び出して、その構成に基づいてプロパティを注入することができます。

于 2009-04-01T04:41:26.630 に答える
1

Glenn Blockによって説明されているように、 IServiceLocatorを見たいと思うかもしれません。

これは、コンテナーに強く依存することなく、IoC を利用するために使用できる共有インターフェイスです。

于 2009-04-01T13:49:47.360 に答える