我應該如何建模類之間的關聯

我在我的應用程序中建模域模型。顯然，某些對象關係是關聯的，但這些關聯也具有屬性。例如：我應該如何建模類之間的關聯

美孚可以有一對多的酒吧。但是，該關聯具有屬性，例如該關聯有效的時間範圍。所以，我這樣做的方法如下：

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

我應該如何建模類之間的關聯

回答

相關問題