Fluent NHibernate 私有字段映射答案

【问题标题】：Fluent NHibernate private field mappingFluent NHibernate 私有字段映射
【发布时间】：2014-05-23 13:59:35
【问题描述】：

我已经生成了一些流畅的 NHibernate 代码。它的实体代码如下：

    private ISet<CardPlace> _cardPlace;

    public MagazineType()
    {
        _cardPlace = new HashedSet<CardPlace>();
    }

    public virtual ISet<CardPlace> CardPlace
    {
        get { return _cardPlace; }
        set { _cardPlace = value; }
    }

这个属性的映射如下：

       HasMany(x => x.CardPlace)
            .Access.CamelCaseField(Prefix.Underscore)
            .Cascade.AllDeleteOrphan()
            .Fetch.Select()
            .AsSet()
            .Inverse()
            .LazyLoad()
            .KeyColumns.Add("MAGAZINE_ID");

我不明白的是.Access.CamelCaseField(Prefix.Underscore) 行。为什么它不直接映射到属性，而是映射到私有支持字段？这样做有什么理由吗？

【问题讨论】：

标签： c# nhibernate fluent-nhibernate

【解决方案1】：

如果你删除了

.Access.CamelCaseField(Prefix.Underscore)

映射将映射到属性 getter 和 setter。

该行指示 fluent nhiberate 改为使用该字段。

【讨论】：

我知道，我的问题是为什么要这样做而不是像你说的那样使用属性

【解决方案2】：

这里的答案是/应该/可能是：改进领域模型设计。这里的主要辅助词是“封装”。因为：

我们为什么要尝试创建实体模型（包含所有业务/验证规则）...
...同时保持后门打开，即有公共设置者。

有一篇非常好的文章，深入探讨：

Strengthening your domain: Avoiding setters

让我引用它的摘要（但请仔细阅读该文本）

理论上讲聚合根边界很有趣，但您可能看到的许多域模型只是名义上的边界。
如果域模型仅公开操作和命令，也公开绕过这些操作通过直接访问属性设置器，那么实际上根本就没有边界。
...
让公共二传手留在原地的理由通常用“更容易测试”来表达。根据经验，无效的域对象更令人困惑，更难测试，这仅仅是因为您无法知道您设置的上下文在使用应用程序时实际上是有效的。

文章 (read it please) 中的所有论点都浓缩在最后一段中：

我们可以通过
删除只能通过在我们的域模型上执行的操作和命令来更改的数据的公共设置器来避免这种混淆和可能的额外防御性编码。
再一次，这就是封装的全部意义所在。我们的模型只公开支持的内容，禁止不支持的内容。

注意：嗯，我确实使用了公共设置器，并且我确实使用了“借口”，例如“它对测试更好......

【讨论】：