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.
2
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.
1