1

ソリューションに同じデータにアクセスするプロジェクトがいくつかあるので、後で別のプロジェクトでデータアクセスを実装しています。現在、EF4、汎用リポジトリ、および作業単位パターンを使用しています。依存性注入をサポートするようにデータアクセスを設計しましたが、Ninjectを使用したいと思います。これが私がこれまでに持っているもののサンプルです

public class Account 
{
    public int Id { get; set; }
    public Guid WebId { get; set; }
    public string Firstname { get; set; }
    public string Lastname { get; set; }
    public string Email { get; set; }
    public string Address { get; set; }
    public string Mobile { get; set; }

}

public interface IRepository<T>
{
    IEnumerable<T> Get(Expression<Func<T, bool>> filter, Func<IQueryable<T>);
    T GetById(int id);
    void Update(T dinner);
    void Insert(T dinner);
    void Delete(int id);
    void Save();
}

リポジトリの実装もありますが、ここではスペースとして投稿しません。

私のUnitOfWorkは次のようになります

public class UnitOfWork
{        
    private Repository<Account> _accountRepository;
    public IRepository<Account> AccountRepository
    {
        get
        {
            if (this._accountRepository == null)
            {
                _accountRepository = new Repository<Account>();
            }
            return _accountRepository;
        }
    }       
}

リポジトリを自動解決するようにninjectを設定する方法と場所。これにより、インターフェイスを使用でき、作業単位でインスタンス化する必要がなくなります。これは正しいことですか、それとも私はDIのポイントをすべて間違っていますか？これが私のワーククラスのユニットをどのように見せたいと思うかです

public class UnitOfWork
{
    IKernel _kernel;

    public UnitOfWork()
    {
        _kernel = new StandardKernel();
    }

    private IRepository<Account> _accountRepository;

    public IRepository<Account> AccountRepository
    {
        get
        {
            if (this._accountRepository == null)
            {
                _accountRepository = _kernel.Get<IRepository<Account>>();;
            }
            return _accountRepository;
        }
    }

}
4

1 に答える 1

0

依存性注入は、コンポジションルートと呼ばれる概念を使用する傾向があります。これは、アプリケーションのオブジェクトグラフの構成が行われるアプリケーション内の単一の場所です。

ライブラリ自体では、依存性注入コンテナを使用しません。ライブラリには注入可能なオブジェクトが含まれている場合がありますが、ライブラリベースのツールではなく、アプリケーションベースのツールになる傾向があります。

これが意味するのは、ライブラリのみを作成する場合、そのライブラリで依存性注入コンテナを使用したり、その中にコンテナを構成したりしないということです。代わりに、アプリケーションからの依存性注入を処理するライブラリを作成します。あなたの場合、コンストラクターインジェクションを介して依存関係を受け入れるようにリポジトリーや作業単位などを設計するだけです。次に、ライブラリを使用するアプリケーションで、DIコンテナ（Ninjectなど）を使用して、オブジェクトの作成方法を構成します。

これは多くのことを行います。まず、アプリケーションがオブジェクトの作成方法を制御できるようにします。たとえば、ライブラリをWebアプリで使用している場合は、1つのリクエストの存続期間中存続するリポジトリのインスタンスを作成するようにライブラリを構成できます。ライブラリがこれを行った場合、アプリケーションレベルでこれを制御することはできません。

次に、ライブラリでDIコンテナを使用する場合は、アプリにもDIコンテナが必要になるため、2つのDIコンテナが作成され、さまざまな競合が発生する可能性があります。ほとんどの場合、アプリケーションにはDIコンテナが1つだけ存在する必要があります。

最後に、あなたは古典的な初心者の失敗を犯しています。DIコンテナを、DI自体の概念と混同しています。DIは、クラスを設計する方法、特にオブジェクトの外部からの依存関係を受け入れる方法です。

DIコンテナは、DI自体ではなく、DIを実現するために使用されるツールです。

TL; DR

独自のDIコンテナを持つようにライブラリを設計しないでください。

于 2013-03-16T07:56:30.250 に答える