Repository pattern design for multiple DbSets

Question

I am coding a MVC 5 internet application, and I am now starting to code a generic repository class for each of my controllers.

My question is this: Should I code a different repository for each different DbSet that I have in my DbContext class?

For example, I have the following DbSets in my DbContext class:

public DbSet<File> files { get; set; }

public DbSet<Asset> assets { get; set; }

Should I have two different repository classes, one for the File and one for the Asset DbSet? Or can/should these be coded into one repository class?

Answer 1

Honestly,

I would not bother abstracting Entity Framework behind a repository unless you have a very good reason. You will create more work, make it harder on you in the future, and I believe EF is already a good enough abstraction from the persistence logic.

That being said, if you do want to abstract behind repository, I would create 1 separate class per DbSet. That way, the DbSet can just be a private property on the repository, and you can delegate the calls directly there.

IF you instead decided to combine them into one class, each of your methods would have to check what DbSet to delegate to.