NHibernate:映射到字段或属性?

时间:2022-08-24 15:40:17

When you create your mapping files, do you map your properties to fields or properties :

创建映射文件时,是否将属性映射到字段或属性:

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" assembly="Foo" namespace="Foo.Bar" >
  <class name="Foo" table="FOOS" batch-size="100">
    [...]
    <property name="FooProperty1" access="field.camelcase" column="FOO_1" type="string" length="50" />
    <property name="FooProperty2" column="FOO_2" type="string" length="50" />
    [...]
  </class>
</hibernate-mapping>

Of course, please explain why :)

当然,请解释原因:)

Usually, I map to properties, but mapping to fields can enable to put some "logic" in the getters/setters of the properties.

通常,我映射到属性,但映射到字段可以在属性的getter / setter中放置一些“逻辑”。

Is it "bad" to map to fields ? Is there a best practice ?

映射到字段是否“糟糕”?有最好的做法吗?

7 个解决方案

#1


5  

I map to properties. If I find it necessary, I map the SETTER to a field. (usually via something like "access=field.camelcase").

我映射到属性。如果我觉得有必要,我将SETTER映射到一个字段。 (通常通过“access = field.camelcase”之类的东西)。

This lets me have nice looking Queries, e.g. "from People Where FirstName = 'John'" instead of something like "from People Where firstName/_firstName" and also avoid setter logic when hydrating my entities.

这让我有漂亮的查询,例如“来自FirstName ='John'的人,而不是像”来自第一名/ _firstName的人“这样的东西,并且在保湿我的实体时也避免使用setter逻辑。

#2


2  

Properties are also useful in the case you need to do something funky with the data as it comes in and out of persistant storage. This should generally be avoided, but some rare business cases or legacy support sometimes calls for this.

在数据进入和退出持久存储时,需要对数据进行简单的操作时,属性也很有用。通常应该避免这种情况,但是一些罕见的商业案例或遗留支持有时会要求这样做。

(Just remember that if you somehow transform the data when it comes back out with the getter, NHibernate will (by default) use the return from the getter and save it that way back to the database when the Session is flushed/closed. Make sure that is what you want.)

(请记住,如果你在使用getter返回数据时以某种方式转换数据,NHibernate将(默认情况下)使用getter的返回值,并在会话被刷新/关闭时将其保存回数据库。确保这就是你想要的。)

#3


1  

I map to properties, I haven't come across the situation where I would map to a field... and when I have I augment my B.O. design for the need. I think it allows for better architecture.

我映射到属性,我没有遇到我将映射到一个字段的情况......当我有我增加我的B.O.为需求而设计。我认为它允许更好的架构。

#4


1  

I map to properties because I use automatic properties.

我映射到属性,因为我使用自动属性。

Except for collections (like sets. Those I map to fields (access="field.camelcase-underscore") because I don't have public properties exposing them, but methods.

除了集合(像集合。那些我映射到字段(access =“field.camelcase-underscore”),因为我没有暴露它们的公共属性,但是方法。

#5


1  

Null Objects

Mapping to fields can be useful if you are implementing the null object pattern if your classes. As this cannot be performed (easily) when mapping to Properties. You end up having to store fake objects in the database.

如果要在类中实现null对象模式,则映射到字段会很有用。因为在映射到Properties时无法轻松执行此操作。您最终必须在数据库中存储虚假对象。

HQL

I was unsure that with HQL queries you had to change the property names if you were using a field access approach. ie if you had <property name="FirstName" access="field.camelcase" /> I thought you could still write "From Person where FirstName = :name"; as it would use the property name still.

我不确定使用HQL查询,如果使用字段访问方法,则必须更改属性名称。即如果你有 我以为你仍然可以写“From Person where FirstName =:name”;因为它仍会使用属性名称。

Further discussion on field strategies and Null object can be found here.

关于字段策略和Null对象的进一步讨论可以在这里找到。

Performance

In relation to performance of field vs property on John Chapman's blog It appears there isn't much of an issue in performance with small-midrange result sets.

关于John Chapman博客中字段与属性的表现,似乎小中型结果集在性能上没有太大问题。

In summary, each approach has certain perks that may be useful depending on the scenario (field access allows readonly getters, no need for setters, property access works when nothing special is required from your poco and seems to be the defacto approach. etc)

总之,根据场景,每种方法都有一些特殊的好处(字段访问允许只读getter,不需要setter,属性访问工作,当你的poco没有特殊要求,似乎是事实上的方法等等)

#6


0  

I tend to agree with the answers above. Generally, map to properties for almost everything, then map to fields for collection setters.
The only other place you'd want to map to fields is when you have something:

我倾向于同意上面的答案。通常,映射到几乎所有内容的属性,然后映射到集合设置器的字段。你想要映射到字段的唯一其他地方是你有什么东西:

public class AuditableEntity
{
   /*...*/
   DateTime creationDate = DateTime.Now;
   /*...*/
   public DateTime CreationDate { get { return creationDate; } }
}

#7


0  

I map directly to fields, which allows me to use the property setters to keep track of a property's dirty state.

我直接映射到字段,这允许我使用属性设置器来跟踪属性的脏状态。

#1


5  

I map to properties. If I find it necessary, I map the SETTER to a field. (usually via something like "access=field.camelcase").

我映射到属性。如果我觉得有必要,我将SETTER映射到一个字段。 (通常通过“access = field.camelcase”之类的东西)。

This lets me have nice looking Queries, e.g. "from People Where FirstName = 'John'" instead of something like "from People Where firstName/_firstName" and also avoid setter logic when hydrating my entities.

这让我有漂亮的查询,例如“来自FirstName ='John'的人,而不是像”来自第一名/ _firstName的人“这样的东西,并且在保湿我的实体时也避免使用setter逻辑。

#2


2  

Properties are also useful in the case you need to do something funky with the data as it comes in and out of persistant storage. This should generally be avoided, but some rare business cases or legacy support sometimes calls for this.

在数据进入和退出持久存储时,需要对数据进行简单的操作时,属性也很有用。通常应该避免这种情况,但是一些罕见的商业案例或遗留支持有时会要求这样做。

(Just remember that if you somehow transform the data when it comes back out with the getter, NHibernate will (by default) use the return from the getter and save it that way back to the database when the Session is flushed/closed. Make sure that is what you want.)

(请记住,如果你在使用getter返回数据时以某种方式转换数据,NHibernate将(默认情况下)使用getter的返回值,并在会话被刷新/关闭时将其保存回数据库。确保这就是你想要的。)

#3


1  

I map to properties, I haven't come across the situation where I would map to a field... and when I have I augment my B.O. design for the need. I think it allows for better architecture.

我映射到属性,我没有遇到我将映射到一个字段的情况......当我有我增加我的B.O.为需求而设计。我认为它允许更好的架构。

#4


1  

I map to properties because I use automatic properties.

我映射到属性,因为我使用自动属性。

Except for collections (like sets. Those I map to fields (access="field.camelcase-underscore") because I don't have public properties exposing them, but methods.

除了集合(像集合。那些我映射到字段(access =“field.camelcase-underscore”),因为我没有暴露它们的公共属性,但是方法。

#5


1  

Null Objects

Mapping to fields can be useful if you are implementing the null object pattern if your classes. As this cannot be performed (easily) when mapping to Properties. You end up having to store fake objects in the database.

如果要在类中实现null对象模式,则映射到字段会很有用。因为在映射到Properties时无法轻松执行此操作。您最终必须在数据库中存储虚假对象。

HQL

I was unsure that with HQL queries you had to change the property names if you were using a field access approach. ie if you had <property name="FirstName" access="field.camelcase" /> I thought you could still write "From Person where FirstName = :name"; as it would use the property name still.

我不确定使用HQL查询,如果使用字段访问方法,则必须更改属性名称。即如果你有 我以为你仍然可以写“From Person where FirstName =:name”;因为它仍会使用属性名称。

Further discussion on field strategies and Null object can be found here.

关于字段策略和Null对象的进一步讨论可以在这里找到。

Performance

In relation to performance of field vs property on John Chapman's blog It appears there isn't much of an issue in performance with small-midrange result sets.

关于John Chapman博客中字段与属性的表现,似乎小中型结果集在性能上没有太大问题。

In summary, each approach has certain perks that may be useful depending on the scenario (field access allows readonly getters, no need for setters, property access works when nothing special is required from your poco and seems to be the defacto approach. etc)

总之,根据场景,每种方法都有一些特殊的好处(字段访问允许只读getter,不需要setter,属性访问工作,当你的poco没有特殊要求,似乎是事实上的方法等等)

#6


0  

I tend to agree with the answers above. Generally, map to properties for almost everything, then map to fields for collection setters.
The only other place you'd want to map to fields is when you have something:

我倾向于同意上面的答案。通常,映射到几乎所有内容的属性,然后映射到集合设置器的字段。你想要映射到字段的唯一其他地方是你有什么东西:

public class AuditableEntity
{
   /*...*/
   DateTime creationDate = DateTime.Now;
   /*...*/
   public DateTime CreationDate { get { return creationDate; } }
}

#7


0  

I map directly to fields, which allows me to use the property setters to keep track of a property's dirty state.

我直接映射到字段,这允许我使用属性设置器来跟踪属性的脏状态。