I am building an ASP.Internet MVC application and I am utilizing a repository to keep and retrieve view objects. My real question is, could it be okay for that implementation of the several databases to call one another? I.E. can the ICustomerRepository implementation call an implementation of IAddressRepository, or should it handle its very own updates towards the address databases?


Thanks everybody, the the clientOrDeal with example is not real. The particular problem involves three aggregates which update a 4th aggregate in reaction to alterations in their particular states. I within this situation it appears a conflict between presenting dependencies versus breaking the don't repeat yourself principle.

You ought to have a repository for every aggregate root.

I've no understanding of the domain-model, however it does not feel natural that i can come with an IAddressRepository. Unless of course 'Address' is definitely an aggregate root inside your domain.

Actually, in many conditions, 'Address' isn't even an entity, but something object. That's, generally the identity of the 'Address' is dependent upon its value (the need for its qualities) it doesn't possess a separate 'Id' (key) area.
So, when this is actually the situation, the CustomerRepository should result in storing the Address, because the Address is an element of the Customer aggregate-root.

Edit (so your circumstances only agreed to be a good example):

But, for those who have other situations in which you would want another repository inside a repository, i quickly think that it's easier to remove that functionality from that repository, and set it inside a separate class (Service). I am talking about: I believe that, for those who have some functionality in the repository A, that depends on another repository B, than the type of functionality does not belong inside repository A.
Rather, write another class (that is known as something in DDD), in in which you implement this functionality.

Anyway, I don't believe that databases should certainly call one another. Should you don't want to create something however, and when you want to help keep that logic within the repository itself, then pass another repository being an argument for the reason that specific method.

I really hope I made myself a little obvious. :P

They should not call one another. A Repository is definitely an abstraction from the (pretty much) atomic procedures that you would like to do in your domain. The less dependency they've, the greater. Reasonably, any consumer of the repository should be prepared to have the ability to point the repository class in a database and also have it carry out the necessary domain procedures without lots of configuration.

They ought to also represent "aggregates" inside your domain - i.e. key points of interest that many functionality depends around. I am wondering the reason why you might have another address information repository? Should not that participate your customer repository?

This is dependent on the kind of repository (or at best the effects do) however in general for those who have data databases calling one another you are likely to encounter issues with such things as cyclical (repo A -> requires B -> requires C -. oops, takes a) or recursive data loads (A-> requires B &lifier C -> C-requires D, E -> .... ->..ad nauseum). Testing also gets to be more difficult.

For instance, you have to load your address repository to correctly run your customer repository, since the customer repository calls the address repo. If you want to test the client repo, you will need to perform a db load from the addresses or mock them in some manner, and ultimately you will not have the ability to load and test any single system repository without loading all of them.

Getting individuals dependencies can also be type of insidious because they are frequently not obvious - usually you are handling a repository like a data-holding abstraction - if you need to take heed to the way they rely on one another you cannot rely on them being an abstraction, but need to manage the burden process without notice for their services.