【问题标题】:how do you name (and map) a backing property?您如何命名(和映射)支持属性?
【发布时间】:2012-01-26 05:18:04
【问题描述】:

在某些情况下,出于实际原因,我有一个属性需要“支持属性”。

例如,我有一个具有 Name 属性的类型 - 访问时不会发生值的转换,它只是触发某种动作;一个副作用,如果你愿意的话。 (这并不是为了讨论,而是在这种特殊情况下,名称在更改时会被复制到其他地方。)

假设:

public class Person
{
    private string __name;

    protected internal virtual string _name
    {
        get
        {
            return this.__name;
        }
        set
        {
            this.__name = value;
        }
    }

    public virtual string Name
    {
        get
        {
            return _name;
        }

        set
        {
            _name = value;

            // action when changing the name takes place here...
        }
    }
}

所以“_name”属性映射到数据库,但保持受保护/内部,因此不能直接修改。第二个公共属性“名称”提供实际访问权限。

我以这种方式设置它的原因是,如果该操作直接构建到映射的“_name”属性的设置方法中,它将在从数据库中水合对象时触发,这不是我的想要。

这一切都很好。

问题是,当您需要查询此类型时,尝试查询 Person.Name 将不起作用,因为该属性未映射!

我对此不满意的是,您正在编写针对 Person.Name 的代码,但必须针对 Person._name 编写查询,这容易出错且令人困惑。

有没有更好的方法来解决这个问题?

【问题讨论】:

    标签: nhibernate mapping backing-field


    【解决方案1】:

    您可以使用 nosetter.camelcase-underscore 来进行映射中的访问吗?这将直接设置字段(如果命名正确,例如_name),而不是使用属性设置器。

    例如:

    <property name="Name" column="Name" type="String" access="nosetter.camelcase-underscore"/>
    

    【讨论】:

    • 所以这直接映射支持字段,并且不需要这样的属性? (与映射属性相比,这样做是否有惩罚或其他副作用?)
    • 是的,完全正确。没有惩罚 - 这是精确映射属性的首选方式,因为它避免了属性 getter/setter 中代码的副作用。
    • 顺便说一句,我不认为“nosetter”避免了 getter 的副作用,只有 getter,不是吗?您是否必须使用“字段”访问来避免吸气剂? (并不是说吸气剂会引起副作用)对于其他研究这些东西的人来说,以下帖子也非常有用:stackoverflow.com/questions/2339264/…
    猜你喜欢
    • 2022-12-22
    • 2013-05-10
    • 1970-01-01
    • 2015-05-15
    • 2018-03-27
    • 1970-01-01
    • 2022-11-23
    • 2018-07-13
    • 1970-01-01
    相关资源
    最近更新 更多