0
クイックQがあります。作業単位とL2S DataContext
実際のデータアクセス技術から切り離されたリポジトリパターンが必要ですが、これについてはまだ決めていないので、柔軟にしたいと思います。だから、これはL2S、L2E、NHibernate、Lightspeedなどである可能性があります。
しかし、私はこのUnitOfWorkについて混乱しています。
L2S世界では、これはあなたのDataContextのようです。
しかし、L2S以外の世界では、たとえば手書きのSQLを使っていたとします。
私の質問は誰ですか?私のRepo.Save()メソッドでは、これはUnitOfWork.Commitをコールして、必要なINSERT/UPDATE SQLを生成しますか?
明確な回答は期待できませんが、正しい議論ができることを確認するために、いくつかのディスカッションはうまくいくでしょう。
おかげ
いくつかのこと:それは消費者が複数のリポジトリに係合することを可能にする作業インスタンスのユニットの寿命を制御するために、消費者を可能にしますので、私は、後者のシナリオを好みます。 1)永続化技術は、DataContext(L2S)を使用してドメインにリークしています。 2)DataContextはリポジトリのコンテキスト外で使用することができます。クライアントは単にDataContextを使用して独自のクエリを生成することができるため、リポジトリは必要ありません。 –
IoCコンテナは、これらの問題の両方を解決できます。 IUnitOfWorkはSubmitChangesメソッドを必要とするだけです。つまり、それを使用するクライアントはデータコンテキストにアクセスできません。 DataContextの部分クラスにIUnitOfWorkを実装することができます。リポジトリの場合は、代わりにIoCコンテナからインタフェース経由で解決する必要があります。これらのリポジトリの具体的な実装では、コンストラクタを介して具体的なDataContextクラスを注入できます。 – mvr