11

次のテクノロジに基づくプロジェクトで、Ninject 2 (昨日、MVC 拡張プロジェクトを含む Github からダウンロード) の使用を開始しました。

  • .Net 3.5 SP1
  • ASP.NET MVC 1.0
  • LINQ to SQL

ここには魔法のようなものは何もありません - ランタイム コードで LINQ to SQL を使用して (および単体テスト コードでハッシュテーブルを使用して) 実装されたリポジトリ インターフェイス (IEntityRepository のような名前) がいくつかあります。これらの各リポジトリは、データベースと対話するために LINQ から SQL への DataContext のインスタンスを必要とするため、具体的なリポジトリ クラスのコンストラクター パラメーターになります。バインディングは次のように設定されます。

Kernel.Bind<MyDataContext>().ToSelf().InRequestScope();

この理由は、エンティティがさらに必要になった場合に、異なるリポジトリ間でエンティティを共有できるようにしたいためです。 HttpRequest。

私は通常、MyDataContext にパラメーターなしのコンストラクターを使用します。これはテスト システムの内部プロジェクトに使用されるため、リスクとは見なされません。そのため、datacontext の "組み込み" 接続文字列は無害です。ただし、Ninject 2 は「貪欲」であり、MOST パラメーターを持つコンストラクターが必要であり、[Inject]意味のある方法で生成されたコードにパラメーターを実際に貼り付けることはできないため、Ninject がコントローラーの 1 つを作成しようとするたびにエラーが発生します (これはデータコンテキストを必要とするリポジトリが必要です)。

コンストラクターを常に LEAST パラメーターで使用する「逆」のものを作成する機能についての言及と機能を見てきIConstructorScorerましたが、これにより、他のすべての注入のしくみが変わります-デフォルトの動作は、おそらくすべてに必要なものですしかし、データコンテキスト。

では、このバインディング (およびこのバインディングのみ) が特定のコンストラクターを使用する必要があることを指定する、すてきでクリーンな方法はありますか? Ninject 1 の場合と同じことをプロバイダーで行うことはできますか?おそらく独自の「ファクトリー」を提供できますか? それとも、あきらめて、意味のあるデータコンテキストにパラメーターをフィードしようとする必要がありますか?

4

2 に答える 2

7

カスタムプロバイダーの実装を回避するために「ToMethod」バインディングを使用することもできると思います。それが私がそれを使用する方法です。

Kernel.Bind<MyDataConext>().ToMethod(c => new MyDataContext())
于 2010-05-02T10:17:48.333 に答える
6

それを考え出した-プロバイダーにバインドすることで非常に簡単に実行できます。

Kernel.Bind<MyDataContext>().ToProvider<ContextProvider>().InRequestScope();

Ninject は、厄介な DataContext オブジェクトの 1 つを構築する必要があるときはいつでも、私の ContextProvider を呼び出すようになりました。これは私のプロバイダクラスがどのように見えるかです:

public class ContextProvider : IProvider
{
    #region IProvider Members

    public object Create(IContext context)
    {
        return new MyDataContext();
    }

    public Type Type
    {
        get { throw new NotImplementedException(); }
    }

    #endregion
}

私はそれでうまくいったようです-それはうまくいきます。:)

于 2009-07-22T12:56:10.637 に答える