repositories objects in business object methods

I thought in the past that my Domain objects shouldn't contain repositories calls in its method. However I faced with following issue.

I know that domain objects must be always in integrated state. For example if you have rule that Order can't exist without order line, you need to add orderLine in order constructor and make LineOrder collection read only.

In my case if order moves to Approved state I need to check if Customer has enough money to order and if application can make transfers for this customer and then assoc transfer to order. So my order.Approve method requires to call corresponding repositories methods to check if it is possible to approve an order and get required navigation properties (Order - Transfer association).

If I don't make this checks and assignments in approve method and create approve m开发者_开发百科ethod in OrderService class (as approve may be considered as process), then my approve method may lead object to not integrated state if someone call it in other code part.

So my questions are: 1. If it is not right to use repositories in domain object methods then how to solve the object's integrity issue above?

2. If Approve is not process then what is the process in customer, order sample? :)

Maybe you should take into consideration that a single entity can have multiple validation contexts.

The answers to your question: 1) You shouldn't use repositories inside your domain models. 2) Approve seems more like a service related concern, not related to your order.

NHibernate and EntitiFramework solves this problem by lazy loading (on demand) the subitems required.

Example

 foreach(var transfer in myOrder.Customer.Transfers)

By accessing myOrder.Customer the customer object is loaded from Database.

By accessing myOrder.Customer.Transfers the tranfers-collection is loaded from Database.

This way there is no need to access a repository.

Here is an example how the need for a repository in a business method can be eliminated: how-to-create-fully-encapsulated-domain-models.