I fear I'm asking a somewhat silly question, but I'm now completely lost as to which principle I should follow.
To my understanding - in terms of Single Responsibility Principle it's best we don't tweak OR inject services into OR introduce extra fields in DB Context.
Simply because the purpose of DB Context is to provide database access.
The single responsibility principle is a computer programming principle that states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. Robert C. Martin expresses the principle as, "A class should have only one reason to change."
The reason why I'm posting this - I'm trying to refactor Service Layer code and would like to make my app set some fields automatically (e.g.
DeleterUserId) rather than manually set all of them each time - fore more info check this.
If you look at the answer the person says
UserId and TenantId here are just pieces of data that your repository service (here a DbContext) needs. If a service needs data, it should be injected into the service.
also one of the comments
Giving your DbContext open access to the session state or the Http context is clearly wrong. But having your DbContext depend on a small number of fixed parameters is fine. Both the UserId and the TenantId might be necessary to connect to the correct database using the correct identity and record audit data. All well within the single responsibility of the repository.
But I also received different feedback from another person under this post.
Here's the answer
You should really think about whether your database context having a dependency on your tenant provider is the right thing to do. As per SRP, your database should only do a single thing and that is provide database access.
Depending on how your tenant provider affects your database access, it might make more sense to move this dependency up one level into some service that uses both the database context and the tenant provider to query data in the right way.
The opinions seem to differ. Does anyone have any recommendations?