EntityFramework
POCO
クラスからテーブルを作成できます。これRepository pattern
により、データベースの概念の上に抽象化レイヤーを作成できるため、実際のアプリケーションのプログラミングに集中できます。
しかし、その後、UnitOfWork
(UoW)パターン。これは、特にEFと組み合わせて、Web上で大いに宣伝されているパターンです。
私は複数のリポジトリを使用していますが、アトミックな方法で何かをコミットする必要があります。次に、すべてのUoWの例で、SaveChanges
他に何もしないメソッドを実装し、呼び出しをに渡すことがわかりDbContext.SaveChanges
ます。それは少し薄い感じなので、おそらくポイントを逃します。それともラッパーにUnitOfWork
すぎませんか?DbContext
シナリオ例:
MultiTenantWebアプリケーションがあります。新規Tenant
を作成する場合、を作成したTenant
ユーザーは、新しく作成したのユーザーとしても保存する必要がありますTenant
。新しいものを作成し、私の現在のケースでTenant
最初に割り当てるのを担当するクラスは、クラス自体です。何かが失敗した場合、どちらもデータベースに保存されるべきではありません。User
Tenant
Tenant
User
私が今これを処理する方法は、DbContext.SaveChanges
すべてのアクションが正常に実行される前にが呼び出されないということです。
誰か(実際のEFソリューションで実際にUoWを使用しているこのドメインの専門家を好む)は、UnitOfWork
過度に依存することの利点を説明できDbContext
ますか?
専門家は命名規則についても教えてもらえますか?解釈のために長くTenantAndUserUnitOfWork
自由に私を襲います(オブジェクト指向の世界であなたが期待するものではありませんか、それとも私は間違っていますか?)