4

EntityFrameworkPOCOクラスからテーブルを作成できます。これRepository patternにより、データベースの概念の上に抽象化レイヤーを作成できるため、実際のアプリケーションのプログラミングに集中できます。

しかし、その後、UnitOfWork（UoW）パターン。これは、特にEFと組み合わせて、Web上で大いに宣伝されているパターンです。

私は複数のリポジトリを使用していますが、アトミックな方法で何かをコミットする必要があります。次に、すべてのUoWの例で、SaveChanges他に何もしないメソッドを実装し、呼び出しをに渡すことがわかりDbContext.SaveChangesます。それは少し薄い感じなので、おそらくポイントを逃します。それともラッパーにUnitOfWorkすぎませんか？DbContext

シナリオ例：

MultiTenantWebアプリケーションがあります。新規Tenantを作成する場合、を作成したTenantユーザーは、新しく作成したのユーザーとしても保存する必要がありますTenant。新しいものを作成し、私の現在のケースでTenant最初に割り当てるのを担当するクラスは、クラス自体です。何かが失敗した場合、どちらもデータベースに保存されるべきではありません。UserTenantTenantUser

私が今これを処理する方法は、DbContext.SaveChangesすべてのアクションが正常に実行される前にが呼び出されないということです。

誰か（実際のEFソリューションで実際にUoWを使用しているこのドメインの専門家を好む）は、UnitOfWork過度に依存することの利点を説明できDbContextますか？

専門家は命名規則についても教えてもらえますか？解釈のために長くTenantAndUserUnitOfWork自由に私を襲います（オブジェクト指向の世界であなたが期待するものではありませんか、それとも私は間違っていますか？）

4

1 に答える 1

3

UnitOfWorkパターンはEFアプリケーションに価値を付加しますか？

作業単位は、ドメイントランザクションを表す良い方法です。それで、それを使用するアプリケーションに価値を追加しますか（Entity Frameworkまたはその他の基盤となるストレージアプローチのいずれか）？

はい：優れたソフトウェアは、いくつかのシナリオで不可分操作を実装する必要があります。

  • ユーザーを登録して、そのプロファイルを作成する必要があります。
  • 注文を削除して、削除されたことをユーザーに通知する必要があります。
  • ..。

すべてが作業単位の一部である可能性があります。

回答：はい、本格的なソフトウェアを作成したい場合はそうです。

于 2013-01-26T18:43:09.683 に答える