リポジトリ対UnitOfWork

Question

私の現在の視点は、リポジトリにはAdd、Deleteなどのエンティティ固有の変更メソッドを含める必要があり、UnitOfWorkには一般的にCommit（SaveChanges、 SubmitChanges）とロールバック（ClearChangesとも呼ばれます）。しかし、UnitOfWorkについての彼のarticleのMartin Fowlerは、すべての修正方法をUnitOfWorkに追加することを提案しています。

これで、EFとNHibernateの世界ではどちらの方が良いのでしょうか？ 最終的に私の好むアプローチでも、リポジトリを通じたすべての変更は、EFコンテキストまたはNHibernateセッションに組み込まれたUnitOfWorkに入ります。私のUnitOfWorkは、UnitOfWorkManager（内部ORM UnitOfWorkを管理する）のようなものです。

Answer 1

UNessionで実装されたUnitOfWorkのNHibernateの主な機能では、 ISessionは何が変更されたのかを追跡し、RegisterCleanやRegisterDirtyのようなメソッドを持つ必要はありません。大規模なプロジェクトの場合、UnitOfWorkと呼ばれる独自のクラスを使用して、ISessionを非表示にすると便利です。例えば：

public class UnitOfWork { 

    private readonly ISession _session; 

    public void BeginTransaction(); 

    public void Commit(); 

    public void Rollback(); 

    public IRepositoryFactory AllRepositories; 
} 

は、アプリケーションコードからISessionを隠すことの利点は、このコードが良好積層を強制直接NHibernateは参照しないことです。言い換えれば、アプリケーション層がデータアクセス層をバイパスしてNHibernate APIを直接使用することは難しくなります。

リポジトリ自体が新しいオブジェクトを追加し、おそらく削除するためのメソッドが含まれます。

public interface IOrdersRepository { 

    public IList<Order> FindPending(); 

    public void AddNew(Order order); 

    public void Delete(Order order); 
} 

Answer 2

これらは、2つの異なるパターンです。

リポジトリは、上位層からのデータストレージの抽象化を担当し、ユニットオブワークは業務トランザクション管理を担当します。リポジトリでは、コードを変更せずにストレージを置き換えることができます。テキストファイル、XML、データベースなどを操作できます。 UoWを使用すると、エンティティの変更を制御して追跡し、一度に1つのビジネストランザクションのすべての変更を保持することができます。

EFとNHの両方がデフォルトでUoWをサポートしているため、自分で再実装する必要はありません。これらのORMはそのままでは提供されないので、独自のリポジトリパターンを作成したいと思うでしょう。

NHとEFの上には不要な抽象化レベルがあり、反パターンとみなすことができます。

この記事では、Fowlerは実際にUoWにデータ操作の責任を追加することを提案していません。彼が言っていることは、トラックのオブジェクトを変更し、必要に応じてそれらをフラッシュ/ロールバックすることができるということです。