My team currently has a project with a data access object composed like so:

public abstract class DataProvider 
     public CustomerRepository CustomerRepo { get; private set; }
     public InvoiceRepository InvoiceRepo { get; private set; }
     public InventoryRepository InventoryRepo { get; private set; }
     // couple more like the above

We have non-abstract classes that inherit from DataProvider, and the type of "CustomerRepo" that gets instantiated is controlled by that child class.

public class FloridaDataProvider 
     public FloridaDataProvider() 
          CustomerRepo  = new FloridaCustomerRepo(); // derived from base CustomerRepository
          InvoiceRepo = new InvoiceRespository();
          InventoryRepo = new InventoryRepository();

Our problem is that some of the methods inside a given repo really would benefit from having access to the other repo's. Like, a method inside InventoryRepository needs to get to Customer data to do some determinations, so I need to pass in a reference to a CustomerRepository object.

Whats the best way for these "sibling" repos to be aware of each other and have the ability to call each other's methods as-needed? Virtually all the other repos would benefit from having the CustomerRepo, for example, because it is where names/phones/etc are selected from, and these data elements need to be added to the various objects that are returned out of the other repos.

I can't just new-up a plain "CustomerRepository" object inside a method within a different repo, because it might not be the base CustomerRepository that actually needs to run.

  • I hate to be cargo-cult, but DI solves a lot of these type of problems. Not only can you use the IoC container to control instance lifecycle, but you can configure different implementations per requester (the CustomerRepo can get a ReadonlyInvoiceRepo injected, for instance). – Bryan Boettcher Aug 21 '14 at 21:02
  • What IoC container do you typically recommend/use for C# projects, insta? – Graham Aug 22 '14 at 11:51

First, lets ignore fact, that repositories are stupid idea in the first place.

Like, a method inside InventoryRepository needs to get to Customer data to do some determinations

Your repositories are quire obviously breaking single responsibility principle. The fact that your repository is pulling data from the DB and adding some behavior on top of it is clear indication of this. The way to solve this is simple. Leave the data loading logic in repository and create separate class for doing the additional logic.

  • One of your links says "that the repository pattern is not flawed, or a bad idea in general". And I'm not sure you ever did answer the question. – david.pfx Aug 23 '14 at 10:32

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.