Question

标题需要起作用，但我能想到的最好的解释是一个例子。

假设您有一个对象“Note”，它表示可以附加到系统中其他类型对象的注释，如Account，Appointment或其他内容。注释仅具有日期和注释的内容，并且只能应用于另一个对象的一个实例。

哪个更好：

一种类型的Note，可以对未应用的类型进行空引用（注意将引用该注释的约会，但对于系统中的帐户/其他对象，它不为null）
多个音符类型（AppointmentNote，AccountNote），它复制相同的逻辑，但避免使用无关的音符引用。

请记住，这些是持久化类，我不希望通过使用子类注释类型在技术上使事情复杂化。在这种情况下，我想尽可能保持域名平坦。

Answer 1

哪个更好：


一种类型的Note，可以对未应用的类型进行空引用（注意将引用该注释的约会，但对于系统中的帐户/其他对象，它不为null）

多个音符类型（AppointmentNote，AccountNote），它复制相同的逻辑，但避免使用无关的音符引用。

都不是。另外，我不清楚我们是在谈论你的物品还是你的桌子。

有一种说明。它根本不应该引用与之相关的对象。

public class Note 
{
   public DateTime CreatedAt { get; set; }
   public string Content { get; set; }
}

public class Account 
{
    public ICollection<Notes> Notes { get; }
}

public class Appointment 
{
    public ICollection<Notes> Notes { get; }
}

然后有几种方法来布置数据库表，这两种方法都应该很容易支持任何ORM（虽然不一定容易支持非真正的ORM-but-half-looks -like-one，例如Linq2SQL或SubSonic，每个数据库表生成一个类的工具。）

第一个数据库布局：

TABLE Notes 
(
     Id,
     CreatedOn,
     Content,
     AccountId,
     AppointmentId
)

那么如果n-1个外键为空怎么办？这是每类class -heirarchy样式，并且它被接受为具有null且对某些子类无意义的列。

第二种方法：

TABLE Notes
(
   Id,
   CreatedOn,
   Content
)

TABLE AccountNotes
(
    AccountId,
    NoteId
)

TABLE AppointmentNotes
(
    AppointmentId,
    NoteId
)

这将更像是每班一次的布局。没有什么说你在代码中实际上需要子类注释类型 - 但即使你这样做，为了避免“打击你的工具”，它并不意味着重复逻辑 - 只需使用基类型并将你的行为放在那里。 p>

最后，你将不得不选择。约会的注释与账户注释本质上是不同的，你将不得不在某种程度上处理它。

Answer 2

为什么不只是其他对象引用的单个Note类？约会，帐户等只会有一个Note对象的通用列表。

DDD：与许多其他人中的一个相关的对象，或者与其他一个相关的许多对象？

2 个答案: