タグ付けされた質問 「unit-of-work」

就職の面接中に、私はリポジトリパターンがEntity FrameworkのようなORMと連携するのに適したパターンではない理由を説明するように求められました。これはなぜですか？

203 asp.net-mvc  entity-framework  unit-of-work 

リポジトリを実装します。リポジトリのコンシューマは複数の操作を実行でき、一度にコミットしたいので、UOWパターンを使用したいと思います。 問題に関するいくつかの記事を読んだ後、他の方法で行われている記事によっては、この2つの要素を関連付ける方法がまだわかりません。 UOWはリポジトリの内部にある場合があります。 public class Repository { UnitOfWork _uow; public Repository() { _uow = IoC.Get<UnitOfWork>(); } public void Save(Entity e) { _uow.Track(e); } public void SubmittChanges() { SaveInStorage(_uow.GetChanges()); } } そして時々それは外部です： public class Repository { public void Save(Entity e, UnitOfWork uow) { uow.Track(e); } public void SubmittChanges(UnitOfWork uow) { SaveInStorage(uow.GetChanges()); …

17 design-patterns  architecture  unit-of-work  repository-pattern 

私の質問は、Stack Overflowでのこれと同様です。ビジネスレイヤー内で作業ユニット/リポジトリを使用する正しい方法は何ですか？ シナリオ： .Netソリューション DBからオブジェクトを取得するために使用されるIRepository IUnitOfWorkを使用して複数のリポジトリ間でトランザクションを許可 これは私には理にかなっていて、私はこれらの線に沿ってうまく機能する何かを実装しました。ここで、ビジネスロジックレイヤーを紹介したいと思いますが、3つの要素（BLL、UnitOfWork、およびリポジトリ）を整理することに頭が悩んでいます。 私の理解： リポジトリ-データの取得、操作 UnitOfWork-永続性 BLL-ビジネスに関連するロジック（「現実世界」）（その用語は嫌いです！） ASP.Net MVCフロントエンドがあるとします。 BLLはどのように見え、それを使用するMVCコントローラーはどのように見えますか？ 参考までに：私のIUnitOfWork / IRepository実装が私の混乱の根本的な原因であるのではないかと思います。 public class IRepository<T> { private IObjectSet<T> objSet; public IRepository<T>(IUnitOfWork uow) { objSet = uow.CreateObjectSet<T>(); } public IQueryable<T> Add(T entity) { objSet.Add(entity); } //etc. etc. for delete, attach, getall } したがって、BLLがある場合は、それをIUnitOfWorkに渡して、必要なIRepositoryインスタンスを作成できるようにする必要があるように感じます。しかし、BLL（フロントエンドとは別のDLL）は、ビルドするIRepositoryの実装をどのように「認識する」のでしょうか。

8 architecture  business-logic  unit-of-work  repository-pattern