我应该如何建模类之间的关联

我在我的应用程序中建模域模型。显然，某些对象关系是关联的，但这些关联也具有属性。例如：我应该如何建模类之间的关联

美孚可以有一对多的酒吧。但是，该关联具有属性，例如该关联有效的时间范围。所以，我这样做的方法如下：

public interface Association<S, T> { 
    public S getSource(); 

    public T getTarget(); 
}

那么对于像上面：

public class FooToBarAssociation implements Association<Foo, Bar> { 
    public Foo getSource(); 
    public Bar getTarget(); 
    public Date getFromDate(); 
    public Date getToDate(); 
}

然后Foo类有：

private List<FooToBarAssociation> associations;

我的问题是：

这是一个适用的通过属性来建模关联的方式？
业务逻辑应该在哪里添加/删除关联到Foo？创建FooToBarAssociation有时需要一些业务逻辑，我想知道是否应该在FooService中处理，然后调用setAssociations而不是在模型对象中。我一直听说尽可能保持模型对象的biz逻辑。

来源

2010-03-09 sma

恕我直言相同的规则适用于当你在UML中实现关联类。你创建的是一种方式，其他可能是嵌套 - Foo包含Assoc，后者又包含Bar。你可以创建它，也可以围绕包含Assoc和Assoc的Foo包含其他方式。 Foo可以包含Assoc和Bar，可以包含Assoc。有很多可能性，这只取决于你的要求。在你的例子中，你的解决方案看起来不错。你听到的似乎很好，但有时可能会变得复杂。

来源

2010-03-09 23:28:08

不会将模型对象中的业务逻辑导致贫血域模型？这是可取的吗？ – 2010-03-09 23:31:42

当你正在建模时，贫血模型是很好的，当你编程时是坏的。为了说清楚，使用贫血模型，您可以轻松使用它，在更高级别的抽象层次上对其进行修改。但是，如果您的模型已设置并且只需填充数据，那么业务逻辑应该位于模型对象中，这就是DDD和MVC模型如何工作AFAIK。在该设置中，你甚至不需要单独的Assoc类。 – 2010-03-09 23:47:04

问题的答案：

我觉得你的模型是适当的。
在面向领域的模型中，我会将关联逻辑添加到Foo。

我有另一个建议，但它适用于特定的情况。如果您需要该模型一次只能使用一个关联，则下面的简化模型可以工作。

public class Foo { 

    private Date startDate; 
    private Date endDate; 
    private Bar bar; 

    public Date getStartDate() { 
     return startDate; 
    } 

    public Date getEndDate() { 
     return endDate; 
    } 

    public Bar getBar() { 
     return bar; 
    } 


}

其中开始日期和结束日期对应于与Foo相关联的时间段。这样，尽管Foo to Bar是一对多的，但您一次只能在一个Bar上工作。 Foo Bar关联将根据生效日期从数据库中提取，该日期位于开始和结束日期之间。

来源

2013-12-30 16:18:03

我应该如何建模类之间的关联

回答

相关问题