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

dbset entity-framework entity-framework-core repository repository-pattern

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: From the article linked earlier

1
0
9/6/2018 2:56:23 PM

Popular Answer

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?

1
9/6/2018 2:26:49 AM


Related Questions





Related

Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow