实体框架：存储为复杂类型的列表

Question

我对实体框架有点陌生，我有以下场景，我想用实体框架在数据库上持久化：

public class Period
{
    public Period() { }
    public DateTime From { get; set; }
    public DateTime To { get; set; }        
}

public class Class1
{
     public Period Validity {get; set;}
}

public class Class2
{
     public List<Period> Validities {get;set;}
}

我可以将 Class1 配置为一个复杂类型，但我不能坚持 Class2。
我可以坚持将 Class2 配置为实体，但是尝试添加 Class1 时 Class1 不起作用。

而且，Period 不是实体，我不想将其视为实体，我不想在 Period 上放置 ID，因为我的模型对它没有意义。它是一个结构，我必须让它成为一个类，已经。

我想保持现有模型不变。 是否有解决方法或可以让我在较低级别定义映射的方法？

NHibernate 4 可以吗？如果值得的话，我已经准备好将我的所有持久层切换到休眠状态！ 有什么提示吗？

Answer 1

如果您尝试将您的（非贫血的）域模型压缩到 ORM 中，您将始终不得不做出妥协。所以这通常不是一个好主意，除非是非常简单的应用程序。

创建一个持久性模型，该模型由非常简单、只有 getter-setter 的类组成，没有任何逻辑。以适合 EF 的方式制作它们并使用它们来持久化数据。现在将您的持久性模型映射到您的域模型，反之亦然。

这可能看起来有点矫枉过正，但如果您真的想应用 DDD，这是唯一干净的解决方案。尽量保持两个模型接近，以便映射简单。 Automapper 是这种模型到模型映射的好工具。

Answer 2

您在 NHibernate 中使用 can't do exactly what you ask，但我们知道 ORM 都是关于权衡的。你真的从Period 没有 ID 得到什么？您是否曾经尝试使用值相等将来自Class1 的Period 与来自Class2 的Period 等同起来？

我通常更关心 VO 的语义优势而不是它们的形状（无 ID、按值比较等）。换句话说，我认为通过将匿名原始值分组到有名的 VO 中来明确领域概念是比不要将实体误认为值对象或其他方式更重要。

因此，我愿意牺牲一点“纯度”来仍然获得 ORM 的好处，而不必创建额外的“数据模型”层和随之而来的额外映射。

这并不意味着您不应该尝试在 Period 作为实体中找到意义。根据您的上下文，这可能是可能的。 This article 显示了一个解决方案，其中 VO 从其宿主对象看时被视为 NHibernate 组件，但在创建/编辑时被视为实体。这可能是一个不错的中间选择。