public interface IUnitOfWork
{
void Save();
}
TransactionScope
作業単位パターンの独自の実装をすでに提供している異なるO/RM間でのみ切り替えることを計画していると仮定すると(これらのO / RMへのアクセスはリポジトリパターンを使用してカプセル化されます)、アプローチを使用しない理由はありますか?IUnitOfWork
? の代わりに
ありがとうございました
public interface IUnitOfWork
{
void Save();
}
TransactionScope
作業単位パターンの独自の実装をすでに提供している異なるO/RM間でのみ切り替えることを計画していると仮定すると(これらのO / RMへのアクセスはリポジトリパターンを使用してカプセル化されます)、アプローチを使用しない理由はありますか?IUnitOfWork
? の代わりに
ありがとうございました
IUnitOfWorkの実装では、TransactionScope、SqlTransaction、または使用することを選択した手段など、一度に異なるアグリゲート間の変更を「トランザクション化」する技術的手段を使用できます。ただし、これはIUnitOfWorkの必要性を否定するものではありません。
リポジトリは特定の集合体用に設計されています。一度に単一の集計タイプへの変更のみを永続化する場合は、リポジトリのみを使用できます。ただし、異なるアグリゲートを同時に永続化していて、その永続化を「トランザクション化」して、変更がすべてまたはまったく永続化されないようにする必要がある場合は、ここで作業単位パターンが機能します。
あなたの例では、OR / MとしてLinqを使用していて、集計をSQLデータストアに永続化していますが、永続化をTransactionScopeにラップしたいとします。次のようなIUnitOfWork定義がある場合があります。
public interface IUnitOfWork
{
void MarkDirty(IAggregateRoot entity);
void MarkNew(IAggregateRoot entity);
void MarkDeleted(IAggregateRoot entity);
void Commit();
void Rollback();
}
次に、実装は次のようになります。
public LinqTransactionScopeUnitOfWork : IUnitOfWork
{
public void Commit()
{
using (TransactionScope scope = new TransactionScope())
{
foreach (IAggregateRoot root in Changes)
{
//Save root based on how it was marked and what it's concrete type is using Linq.
}
scope.Complete();
}
}
}
ここでの主な考え方は、TransactionScopeはIUnitOfWorkを実装する1つの方法ですが、Unit of Workコントラクトを使用すると、環境に基づいてさまざまな実装を提供できます。
お役に立てれば!
技術的な理由が1つあります。環境でTransactionScopeを使用するのが難しい場合があるため、サービスを開始してファイアウォールポートのロックを解除する必要があります。私はあなたがこれらの問題を抱えていないので、TransactionScopeを使用することをお勧めします:それはすでに行われ/デバッグされています、なぜあなたはもっと良いことをすると思いますか?