Storing DbSet in constructor instead of calling DbContext.Set for every use

Question

In a repository pattern I've been following for a while (example), I've always had Add, Delete, etc. methods which use a "new" DbSet (e.g., DbContext.Set<T>.Update(entity). In testing, this seems to, thankfully, always return the same DbSet object. Is there any reason I should not call DbContext.Set<T>() once in the constructor and save it as a property instead of calling Set<T>() in every method? I just want to make sure I'm not missing something.

This snippet was taken from the same link:

Answer 1

Is there any reason I should not call DbContext.Set() once in the constructor and save it as a property instead of calling Set() in every method?

No. That's exactly what a normal DbContext does on initialization. See What calls the setters in an Entity?