Temo di porre una domanda un po 'sciocca, ma ora sono completamente perso su quale principio dovrei seguire.
Per quanto ne so - in termini di principio di responsabilità singola è meglio non modificare OPPURE inserire servizi in OPPURE introdurre campi extra in Contesto DB.
Semplicemente perché lo scopo del DB Context è di fornire accesso al database .
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."
Il motivo per cui sto postando questo - sto cercando di rifattare il codice del Service Layer e vorrei che la mia app impostasse alcuni campi automaticamente (es. CreatorUserId , ModifierUserId , DeleterUserId ) piuttosto di impostare manualmente tutti loro ogni volta - per maggiori informazioni controlla questo .
Se guardi la risposta la persona dice
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.
anche uno dei commenti
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.
Ma ho ricevuto anche feedback diversi da un'altra persona in questo post .
Ecco la risposta
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.
Le opinioni sembrano essere diverse. Qualcuno ha qualche consiglio?