I am modelling the domain model in my application. Obviously, some of the object relationships are assocations, but those associations also have attributes. For example:
Foo can have one-to-many Bars. However, the association has attributes, such as a date range for how long that association is valid. So, the way I have done this is as follows:
public interface Association<S, T> {
public S getSource();
public T getTarget();
}
Then for something like the above:
public class FooToBarAssociation implements Association<Foo, Bar> {
public Foo getSource();
public Bar getTarget();
public Date getFromDate();
public Date getToDate();
}
Then the Foo class has:
private List<FooToBarAssociation> associations;
My questions are:
Is this an appropriate way to model the association with attributes?
Where should the business logic be for adding/removing the associations to Foo? Creating a FooToBarAssociation will sometimes require a bit of business logic and I'm wondering if that should be handled in a FooService, which then calls setAssociations rather than being in the model object. I've always heard to keep biz logic out of the model objects as much as possible.