私はいくつかのコードを持っています(C#.Net Core WebAPI)私は単体テストをしたいが、依存関係は私に少し奇妙に見えます。IOptionパターン - ユニットのテストとレイヤーの通過
コードは、DbContextとリポジトリの両方が同じ依存性を持っている
...今まで、最初はOKだった。ネットコアWebAPIのを、使用してMongoDBのにアクセスするために(私はウェブ上で発見)いくつかのサンプルコードから来ました - とリポジトリはとにかくDbContextへを通してそれを渡す - リポジトリがDbContextインスタンスとして:
public class LogItemRepository : ILogItemRepository
{
private readonly DbContext _context = null;
public LogItemRepository(IOptions<DbSettings> settings)
{
_context = new DbContext(settings);
}
を...
public class DbContext
{
private readonly IMongoDatabase _database = null;
public DbContext(IOptions<DbSettings> settings)
{
var client = new MongoClient(settings.Value.ConnectionString);
if (client != null)
_database = client.GetDatabase(settings.Value.Database);
}
public IMongoCollection<LogItem> LogItemsCollection
{
get
{
return _database.GetCollection<LogItem>("LogItem");
}
}
}
}
私はOptions patternに精通していませんが、素早く読んでみればよかったです。しかし、私は子の依存関係(オプション)、親の依存関係(上記の例のように)を作るのが良い方法であるとは確信していません。
代わりに、IDbContextというインターフェースを作成して、それをリポジトリーの依存関係として使用する必要がありますか?これは私が過去にやったことですが、これがオプションパターンを破るかどうかはわかりません。
私はこれが主観的だと思っていますが、他にも入力したいと思います。
おかげ ティム
主に意見に基づいていますが、一般的な方法はリポジトリのコンストラクタ内でdbコンテキストをインスタンス化しないことです。リポジトリはコンテキストに密接に結びついています。あなたのOPで述べたように抽象を注入してください。コンテキストのみがNkosiのコメントでオプションの抽象度 – Nkosi
+1に依存しているようです。リポジトリがコンテキストをインスタンス化すると、あらゆる種類の問題が発生します。 5つのリポジトリは潜在的に5つのコンテキストを使用することになります。つまり、渡されたエンティティへの参照/返されたコンテキストは、コンテキストの範囲外に置かれるか、コンテキスト間でエンティティを分離/再接続するための厄介な配線です。単体テスト(TDD/BDDテストのように)では、コンテキストレベルでモックしようとするのではなく、リポジトリレベルでMockをオフにします。 dbとの統合テストでは、リポジトリをテストできます。 –