0

DI を設定しようとして、ちょっとした障害にぶつかりました。

したがって、このコントローラーがあるとします：

public UsersController(IUnitOfWork unitOfWork)
{
   // Stuff
}

以前、リポジトリに直接アクセスするこの UnitOfWork 実装がありました。

public class UnitOfWork : IUnitOfWork, IDisposable
{
  private readonly DbContext _context = new DbContext();

  public IRepository<User> Users { get { return new UserRepository(_context); } }
}

Ninject UnitOfWork コード:Bind<IUnitOfWork>().To<UnitOfWork>().InRequestScope();

これで実際にうまく動作します。ただし、リポジトリを含む UnitOfWork の代わりに、複数のリポジトリを取り込むサービスが含まれるように変更したいと考えています。

public class UserService : IUserService
{
  private readonly IUserRepository _userRepository;
  public UserService(IUserRepository userRepository, /* Other repositories */)
  {
    _userRepository = userRepository;
  }
}

今私が思いつくことができる唯一の解決策は

public class UnitOfWork : IUnitOfWork, IDisposable
{
  private readonly DbContext _context = new DbContext();

  public IUserService UserService
  {
    get
    {
      return new UserService(new UserRepository(_context), /* etc. */);
    }
  }
}

これは正しくないようです。現在、すべてのサービスの依存関係を自分で作成しています。

StackOverflow の投稿で、コントローラー (MVC アプリケーション) に心配させるよりも、サービスに複数のリポジトリにアクセスさせてビジネス ロジックを処理させる方がよいと述べているのを見たことがあります。

ただし、実際にこれを適切に行う方法についての詳細は見つかりません。では、Ninject を使用して目的を達成するにはどうすればよいでしょうか?

4

1 に答える 1

2

申し訳ありませんが、これは本当に大きくなりすぎたコメントですが、ねえ...

ADbContext は作業単位であり、2 つの DbContext にまたがるモンスターの作業単位を作成することは、一般的なパターンではありません (したがって、あなたの質問はあなたを誘惑します)。

関連する質問へのこの回答に関するコメントは、同じ領域に迷い込んでいます。

この方法で解決しようとする前に、次の質問を自問してください。

  • DbContext を持つことを超えて、私のこの Unit of Work で何を達成しようとしていますか?
  • これはトランザクションである必要がありますか?
  • 実際には、他の 2 つのサービスを参照する独自のデータが必要な途中に欠落しているサービスがありますか?
  • これは 2 つの Bounded Context にまたがる必要がありますか? 後でもう一度パーツを引っ張る必要がある場合はどうしますか?
  • 私のアプリにこのケースが 3 つある場合、それらを 1 つの BC にマージし続けますか? 4?

私にとって重要なのは、独自の UoW を作成して UoW をラップすることです。

  1. あまり買わない
  2. あなたの核心の問題について推論するのを難しくします

途中で Ninject にこれを押し込むつもりなら、技術的なアプローチは Context Preservation と Factory Extensions を一緒に使用することです - 彼らの wiki で例を読んでください。物事を取り除こうと決めたとしても、おそらくまだ役割を果たしているでしょう。

更新: 私は今、あなたのドリフトをキャッチします. まず、これを読んでください。次に、作業単位を持つかどうかを決定します。もしそうなら、誰がどこでそれをコミットして破棄するつもりですか?

リポジトリやサービスが UoW または DBContext のいずれかを共有し、何かが中央でコミットされる場合は、それらを InRequestScope の Shared/Disposed にバインドして、a) 単一の共有インスタンスを取得する b) get を取得する廃棄

私の主な懸念は、これらすべての抽象化がすべて実際に利益をもたらすかどうかです.抽象化を使用するテストを本当に書いていますか? 本当にリポジトリを切り替えるつもりですか。個人的には、より良い時間の投資として、DDD の本を数回読みに行きます。

これの多くは非常に愛用されており、これはより大きな問題の一部を表す単純化された質問にすぎないことを認識していますが、最近、ラッピングレイヤーと DI コンテナーのトリックの交差点によって引き起こされた質問が多すぎるため、私の暴言を吐き出しました。暴言完了、ありがとう！

于 2013-04-05T21:18:53.697 に答える