CODEWITHSUNDEEP
design-patternslaravelormrepository
Jacob Greenleaf
Jacob Greenleaf

Reputation: 379

Best practice around the repository pattern?

The repository pattern is used in the context of an MVC web application framework to decouple the particular mechanism of storage retrieval from the Controller.

Whenever I've ended up using this pattern, there ends up being an explosion of methods in the repository class per unique query. For example, in the article I linked earlier there are 7:

  1. Grab all questions asked
  2. Create a bare question for form binding in our views
  3. Grab paginated questions
  4. Create and store a question
  5. Grab a question by its primary key
  6. Update a question with a primary key and some array data
  7. Delete a question by its primary key

I can imagine more:

  1. Grab all questions with an answer
  2. Grab all questions without an answer over a certain age
  3. Grab all questions with certain key words
  4. Grab all questions marked as spam or deleted
  5. Grab all users that asked a question

Basically it seems under this pattern there will be one method per unique set of where clause conditions, such that the methods are isomorphic to unique queries. Is this a bad thing? Is there a more general pattern to be applied to prevent this explosion of methods?

(12) presents a related problem - is a Question repository supposed to leak the details of the relationships that Questions have to Users?

Upvotes: 2

Views: 567

Answers (2)

Alireza Rahmani Khalili
Alireza Rahmani Khalili

Reputation: 2954

here you would find your solutions :

benefits using repositories

eloquent tricks better repositories

creating flexible controllers in laravel 4 using repositories

Upvotes: 0

michal.ciurus
michal.ciurus

Reputation: 3664

What all queries have in common ? Well... they're all queries... :) They all accept some parameters and return some structure object.

You can create a generic abstract interface/class that makes use of that fact:

(C#)

public interface IQueryHandler<TQuery, TResult> where TQuery : IQuery<TResult>
{
    TResult Handle(TQuery query);
}

It will not only help you with decoupling and abstracting all types of queries you mentioned, it is also very useful in Depedency Injection and applying cross-cutting concerns.

These two articles that taught me that explain it in detail:

It's in C#, but you can create a mirror implementation in every language that supports templates (c++, java etc.)

Upvotes: 1

Related Questions