Does it make sense to create a repository that takes a default search criterium as constructor argument?

Question

I'm refactoring a website I build. It's a website for a travel agency. I'm thinking of implementing the repository pattern.

The travel agency has two divisions, that have their own website and target different groups of customers. The backend however is the same for both websites. They both access the same DB tables. Some tables simply have columns that identify what division the records are for.

Let's imagine I want to build a TripRepository, that will be able to return Trip objects. Do you feel it makes sense to create a Repository that takes the Division as a constructor argument? Such that all results will be only for that Division?

So in other words, in pseudo code:

class TripRepository
{
    method constructor( Devision );

    // this will then only return Trips for the Devision passed to the constructor
    method findAllTrips( /* some other criteria */ );
}

I could very well have it as an optional constructor argument of course, and even have a setter to switch Devisions if need be... but in general is there something objectional with doing this?

Or should I just always pass the Devision criterium to all search methods?

Answer 1

Unless your findAllTrips(...) method has completely different logic based on the "Devision" (shouldn't it be Division, btw?) there is no reason to create seperate instances. And even if you do for some reason, I suppose you will have to put the instantiated objects in some other collection, where they will be accessed using... Devision as a key (i.e. parameter).

So personally I think it wouldn't be a good design decision: doesn't look intuitive and whoever meet this in your code in the future will probably wonder what the real motive was to go this route.