2

通常、リポジトリは次のいずれかの方法で実装されていることに気付きました。

方法 1 

void Add(object obj);
void Remove(object obj);
object GetBy(int id);

方法 2

void Save(object obj);     // Used both for Insert and Update scenarios
void Remove(object obj);
object GetBy(int id);

方法 1 にはコレクションのセマンティクスがあります (これがリポジトリの定義方法です)。リポジトリからオブジェクトを取得して変更できます。ただし、コレクションを更新するようには指示しません。この方法でリポジトリを実装するには、メモリ内オブジェクトに加えられた変更を永続化するための別のメカニズムが必要です。私の知る限り、これは Unit of Work を使用して行われます。ただし、システムでトランザクション制御が必要な場合にのみ UoW が必要であると主張する人もいます。

方法 2 では、UoW が不要になります。Save() メソッドを呼び出すと、オブジェクトが新規で挿入する必要があるか、変更されて更新する必要があるかを判断できます。次に、データ マッパーを使用して、データベースへの変更を永続化します。これにより作業がはるかに楽になりますが、モデル化されたリポジトリにはコレクションのセマンティクスがありません。このモデルには DAO セマンティクスがあります。

私はこれについて本当に混乱しています。リポジトリがオブジェクトのメモリ内コレクションを模倣する場合、方法 1 に従ってモデル化する必要があります。

これについてどう思いますか？

モッシュ

4

2 に答える 2

2

個人的には、Unit of Work パターンがソリューションの一部であることに問題はありません。明らかに、CRUD の CUD にのみ必要です。ただし、UoW パターンを実装しているという事実は、バッチとして実行する必要がある一連の操作があることを示しているに過ぎません。これは、トランザクションの一部である必要があると言うのとは少し異なります。リポジトリを十分に抽象化すると、UoW 実装は、使用しているバッキング メカニズム (データベース、XML など) にとらわれなくなります。

具体的な質問に関しては、メソッド 2 のほとんどのインスタンスに識別子が設定されているかどうかを確認するチェックが含まれている以外の理由がなければ、メソッド 1 とメソッド 2 の違いは些細なことだと思います。設定されている場合は更新として扱い、設定されていない場合は挿入として扱います。私の意見では、このロジックはリポジトリに組み込まれていることが多く、公開されたインターフェイスを単純化するためのものです。リポジトリの目的は、コンシューマーとデータ ソースの間でオブジェクトを仲介し、データ ソースの知識を直接持つ必要をなくすことです。アプリケーション全体でオブジェクトの状態を追跡することに頼るよりも、識別子を検出する単純なロジックを信頼しているため、方法 2 を使用します。

リポジトリの使用に関する用語がデータ アクセスとオブジェクト コレクションの両方に非常に似ているという事実は、混乱を招きます。私は彼らを彼ら自身の第一級市民として扱い、ドメインにとって最善のことをします. ;-)

于 2010-09-01T19:06:07.077 に答える
1

多分あなたは持っていたい：

T Persist(T entityToPersist);
void Remove(T entityToRemove);

「持続」は「保存または更新」または「追加または更新」と同じです。Repo は新しい ID の作成をカプセル化します (データベースがこれを行う場合があります) が、常に ID 参照を含む新しいインスタンスを返します。

于 2011-02-11T06:46:25.250 に答える