.NET ORM,不可变值对象,结构,默认构造函数和只读属性

Question

我刚刚开始使用.NET ORM,我还没有在Entity Framework和NHibernate之间做出决定.但在这两种情况下,我遇到了一个问题,因为他们似乎希望我以各种方式破坏我的域模型的完整性,特别是在C#对象设计的更精细点上.这是关于这个问题的几个问题之一.

---

我习惯于使用如下所示的模式在适当的属性上强制使用不变性:

public class Foo
{
    private readonly string bar;
    public string Bar { return this.bar; }

    public Foo(string bar)
    {
        this.bar = bar;
    }
}

这似乎不受NHibernate或Entity Framework的支持.他们想要默认的构造函数和publicsetter; 看起来甚至privatesetter(和默认构造函数)工作(有时？)因为ORM可以使用反射.

我想我可以通过使用privatesetter和private默认构造函数来解决这些问题.至少那时公共API不会受到损害.我正在修改我的所有类的实现以添加未使用的private构造函数,并且必须信任future-Domenic,他private对我的setter 理解的确意味着"除了在构造函数中之外不要打电话给我".持久层泄漏到我的域对象设计中.

它似乎也是不必要的 - 为什么ORM不能知道使用非默认构造函数？也许他们能够,我只是没有找到正确的博客文章解释如何.

最后,在某些情况下,我的不可变值对象实际上很适合(不可变)值类型,即structs.我的猜测是这是可能的,因为在数据库中,我的struct的字段将显示在父实体存储的同一行中.你能确认/否认吗？这篇博文看起来很有前途,因为它给出了肯定的答案,但代码的数量(实际上特定于所讨论的价值类型)却让人头疼.

---

令人沮丧的是,经过几年阅读像Effective C#这样的书或像Eric Lippert那样的博客,它们提供了关于如何设计富有表现力和防弹的C#对象的建议,使用ORM的需要让我把大量的知识从窗口.我希望这里有人可以指出我错在哪里,要么掌握他们的能力,要么是我对域建模和ORM角色的思考.

Answer 1

正如评论所指出的，当/如果你采用 ORM 时，你将不得不做出一些妥协。我认为要记住的是，生产力的提高远远超过这些妥协的“成本”。

我确实想向您指出（因为您是 EF 新手），您可以自定义生成 EF 实体和上下文的T4 模板。我认为如果你尝试一下这个，你可以解决大部分你不喜欢的事情。