Question

我是实体框架的新手，我有以下场景，我想在实体框架上坚持DB：

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将Period配置为复杂类型，但是我不能坚持Class2 我可以坚持Class2将Period配置为实体，但是当尝试添加Class1时Class1不起作用。

而且，Period不是一个实体，我不想把它当成一个实体，我不想在Period上放一个ID，因为我的模型没有意义。这是一个结构，我必须让它成为一个类。

我想保留现有的模型。是否有解决方法或某些东西可以让我在较低级别定义映射？

NHibernate 4可以实现吗？我准备将我的所有持久层切换为nhibernate，如果值得的话！任何提示？

Answer 1

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

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

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

Answer 2

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

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

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

这并不意味着您不应该试图在Period成为实体时找到意义。根据您的具体情况，可能会有所不同。 This article显示了一个解决方案，其中VO在从其主机对象看时被视为NHibernate组件，但在创建/编辑时被视为实体。这可能是一个很好的中间选择。

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

2 个答案: