2

だから私は依存性注入にNinjectを使い始めており、Linq2SqlDatacontextsのようなUnitofWorkタイプのオブジェクトのオブジェクトファクトリとしてカーネルを使用することを人々がどう思っているのか疑問に思っています。通常の依存関係のようにそれらを注入しますが、これにより、回避したいオブジェクトの存続期間の問題がいくつか発生します。DataContextは、必要に応じて新しいインスタンスを起動し、完了したらそれらを破棄することになっているため、一般的な依存関係とは異なります。

このようなことをするために、私は単にそのようなプロバイダーをセットアップするでしょう...

class SomeDataContextProvider : Provider<SomeDataContext>
{
    private static string _connectionString = "someConnectionString"
    protected override SomeDataContext CreateInstance(IContext context)
    {
        return new SomeDataContext(_connectionString);
    }
}

それらをモジュールにバインドします...

class MyModule : Ninject.Modules.NinjectModule
{
    public override void Load()
    {
        Bind<SomeDataContext>().ToProvider(SomeDataContextProvider);
    }
}

そして、必要に応じて標準カーネルを使用してください...

class MyClassThatNeedsADataContext
{
    private StandardKernel _kernel = new StandardKernel(new MyModule());

    public void SomeMethod()
    {
        using (var db = _kernel.Get<SomeDataContext>())
        {
            //Use the context
        }
    }
}

本質的に静的なファクトリであるため、少し重いように見えますが、とにかく他のものにNinjectを使用しています。チームのメンバーに、単にウィングさせるのではなく、ファクトリのコンベンションを提供するのが好きです（奇妙な場所にさまざまなファクトリクラスを作成したり、オブジェクトに静的メソッドを配置したりするなど）。

考え？依存性注入を使用して、DataContextやWCFサービスクライアントなどの作業単位の依存関係を処理するためのより良い方法はありますか？

4

1 に答える 1

6

コンテナーをクラスに注入するのは好きではありません。これは、アプリケーションとコンテナーの間に依存関係が作成され、クラスの依存関係が不明確になるためです。このアプローチがファクトリに対してどのように役立つかはわかりません。個人的には、「DataContextFactory」を作成し、それをデータベースにアクセスする必要があるクラスに注入します。

于 2009-11-17T20:36:12.663 に答える