Domain object relationship where one end may have a large number of occurrences.

[marcioemiranda]

Let's take for example this two (very) common relationships in an e-commerce application:

Account 1xN Order
Department 1xN Item

In both cases the N end of the relationship may contain a lot of occurrences, and thus the application will not load all at once (lazy loading), and will use some logic to get the right ones to the task at hand.

We could certainly use a service layer to load them:

public interface OrderService {

public List<Order> getOrders(Account account, Month moth);
public List<Order> getOrders(Account account, Date begin, Date end);
...
}

But how to implement this relationship in the Account class?

Suppose we expose an Account instance to the client layer. A call to

List<Order> getOrders()

would trigger a lazy loading operation (I'm using iBatis) to retrieve all orders related to an Account, which is not desirable. In fact, I believe I should not even declare this signature in the Account class.

If I had specific methods such as

List<Order> getOrders(Date begin,Date end)

, then I would need to call a service from within the domain object, which does not seem a good practice. How to inject the service is not the problem, since I could use @Configurable, the problem here is that this seems conceptually wrong.

A third option is to define a strategy class (or many) which knows how to load the orders, and then include the following method in the Account class:

public List<Order> getOrders(FilterStrategy strategy)

. The FilterStrategy could be configured in Spring, probably injected with the service. This way we do not need to inject a service into the domain object.

The fourth option is to ignore this relationship altogether in the Account class, and make the client call the service to get the list of orders and handle it the way it wants.

What alternative do you think is best?