I am trying to apply SOLID whenever I can and try to use common sense and avoid a pattern when I see that a pattern is creating more problems than it's trying to solve. I don't want to apply a pattern and make life difficult for somebody else using my code just for the sake I write patterns if you see what I mean.Now I am struggling with one of the principles that I thought was the easiest to grasp: SRP.How do you practically apply this principle to repositories?Let's suppose I have aIEmployeeRepositoryIUserRepositoryIProductRepositoryand commonly they will have methods like these:public interface IUserRepository{    User GetUser(int id);    IEnumerable<User> GetAllUser();    void DeleteUser(int id);}same for employees and products.Are we saying that each of these method should be a class on it's own? even though at times we are talking a single line of code?
How do you apply Single Responsibility principle to a repository
c#;design patterns;solid;repository;single responsibility
Whenever you have a class with more than 1 method, you can question if the SRP is fulfilled, since each of the methods will (typically) solve a different task or problem and so has a different responsibility. But that's actually not the way I understand the SRP - SRP means IMHO single responsibility at the correct level of abstraction. And the level of abstraction for a repository may berepository RX is responsible for providing abstract CRUD operations for class XIn fact, when you start implementing such a repository, it may turn out that some of the member functions of the repo may become so complex that you need additional helper classes to implement them. If that's the case, the repo may turn into a facade, but the responsibilty stays the same - at that level of abstraction.In fact, there is no general rule how to choose the correct levels of abstraction, this is up to your experience and to some degree of your taste.