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 a


and 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?


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 be

"repository RX is responsible for providing abstract CRUD operations for class X"

In 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.

  • 1
    That SRP exists implies the existence of some general rule or guideline. Unless, of couse, it is purely a guideline with no representative examples. That would make it useful for pondering or discussion, but not much else. – Robert Harvey Nov 2 '14 at 18:40

I think you should think who has an interest to change that respective class. For example if you have an User class with an CalculatePay method and a save method. The accountant would want to change the CalculatePay and the DB administrator the save method. These are two different responsibilities.

The SRP means grouping together things that change for the same reason. So the repository shouldn't violate the SRP.

  • 1
    +1. Imo, the best formulation of SRP is "a class should have only one reason to change". In the case of the code in the question, the only reason for changing would be if details of the storage mechanism changed. – Jules Nov 29 '14 at 14:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.