Come si applica il principio di responsabilità unica a un repository

4

Sto provando ad applicare "SOLID" ogni volta che posso e cerco di usare il buon senso ed evitare un pattern quando vedo che un pattern sta creando più problemi di quanti ne stia cercando di risolvere. Non voglio applicare un pattern e rendere la vita difficile a qualcun altro che usa il mio codice solo per il gusto "Scrivo i pattern" se capisci cosa intendo.

Ora sto lottando con uno dei principi che pensavo fosse il più facile da capire: "SRP".

Come si applica praticamente questo principio ai repository?

Supponiamo di avere un

IEmployeeRepository
IUserRepository
IProductRepository

e comunemente avranno metodi come questi:

public interface IUserRepository
{
    User GetUser(int id);
    IEnumerable<User> GetAllUser();
    void DeleteUser(int id);
}

stesso per impiegati e prodotti.

Stiamo dicendo che ognuno di questi metodi dovrebbe essere una classe a parte? anche se a volte stiamo parlando di una singola riga di codice?

    
posta developer9969 02.11.2014 - 18:45
fonte

2 risposte

9

Ogni volta che hai una classe con più di 1 metodo, puoi chiedere se l'SRP è soddisfatto, poiché ognuno di questi metodi (in genere) risolve un compito o un problema diverso e quindi ha una "responsabilità diversa". Ma questo in realtà non è il modo in cui capisco l'SRP - SRP significa IMHO "singola responsabilità al livello corretto di astrazione". E il livello di astrazione per un repository potrebbe essere

"repository RX è responsabile della fornitura di operazioni CRUD astratte per la classe X"

In effetti, quando si inizia a implementare un repository di questo tipo, è possibile che alcune delle funzioni membro del repository possano diventare così complesse da richiedere ulteriori classi di supporto per implementarle. Se questo è il caso, il repository può trasformarsi in una facciata, ma la responsabilità rimane la stessa: a quel livello di astrazione.

In effetti, non esiste una "regola generale" su come scegliere i livelli "corretti" di astrazione, questo dipende dalla tua esperienza e ad un certo grado del tuo gusto.

    
risposta data 02.11.2014 - 18:58
fonte
8

Penso che dovresti pensare a chi ha interesse a cambiare quella rispettiva classe. Ad esempio se si dispone di una classe utente con un metodo CalculatePay e un metodo di salvataggio. Il ragioniere vorrebbe cambiare il CalculatePay e l'amministratore DB il metodo di salvataggio. Queste sono due diverse responsabilità.

L'SRP significa raggruppare cose che cambiano per lo stesso motivo. Quindi il repository non dovrebbe violare l'SRP.

    
risposta data 02.11.2014 - 19:04
fonte