私は、特に汎用リポジトリを使用して、EF でリポジトリ パターンを実装するためのさまざまなアプローチを検討してきました。
IContext プロパティを持つ IRepository を使用しようとしていたため、IRepository の実装間の唯一の違いはコンテキストになります。「偽のコンテキスト」アプローチを放棄し、偽のリポジトリに「コンテキスト」としてリストの辞書を持っているだけで、これは十分に難しいことがわかりました。
public Dictionary<Type, object> _sets = new Dictionary<Type, object>();
そしてそれを操作するには、偽物で次のようにします:
public void Add<T>(T entity) where T : class
{
var set = _sets[typeof (T)] as IQueryable<T>;
var updatedSet = set.ToList();
updatedSet.Add(entity);
_sets[typeof (T)] = updatedSet.AsQueryable<T>();
}
実際のリポジトリでは、次を使用できます。
void Add<T>(T entity)
{
Set<T>().Add(entity);
}
私の Update メソッドでは、DbContext を継承する実際のコンテキストと、コレクション ベースのアプローチを使用する偽物に対応するために、同様に異なる実装が必要になります。
このアプローチは私を緊張させます。他の質問で他の人が言及しているように、私のリポジトリの実装は非常に異なっているため、偽のリポジトリと実際のリポジトリの両方で実行されるまで、テストを信頼できないと感じています。
私はこれを考えすぎているだけの初心者ですか?または、DbContext のように動作する偽のコンテキストを実装するより良い方法があるので、リポジトリ インターフェイスを実装するこのような大幅に異なるクラスを使用する必要はありませんか?
要約すると、インメモリ リポジトリを使用したテストの利点を理解しています。私の質問は、これほど異なるリポジトリの 2 つの実装を作成する必要がある場合、それは私が何か間違ったことをしていることを意味するのでしょうか、それともこれは偽物を使用したテストのコストにすぎないのでしょうか。ロジック テストに合格した場合は、そうすべきです。そんなに汗をかくの?