NHibernate: сопоставление с полями или свойствами?

Question

При создании файлов сопоставления сопоставляете ли вы свои свойства с полями или свойствами:

<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>

Конечно, объясните, пожалуйста, почему:

Обычно я сопоставляю со свойствами, но сопоставление с полями может позволить поместить некоторую «логику» в средства получения / установки свойств.

"Плохо" сопоставлять поля? Есть ли лучшая практика?

Answer 1

Я сопоставляю со свойствами. Если я нахожу это необходимым, я сопоставляю SETTER с полем. (обычно через что-то вроде «access = field.camelcase»).

Это позволяет мне иметь красивые запросы, например "от People Where FirstName = 'John'" вместо чего-то вроде "от People Where firstName / _firstName", а также избегайте логики сеттера при увлажнении моих сущностей.

Answer 2

Свойства также полезны в том случае, если вам нужно сделать что-то необычное с данными, когда они поступают в постоянное хранилище и выходят из него. Этого, как правило, следует избегать, но некоторые редкие бизнес-случаи или устаревшая поддержка иногда требуют этого.

(Просто помните, что если вы каким-то образом преобразуете данные, когда они возвращаются с помощью геттера, NHibernate будет (по умолчанию) использовать возвращаемый результат из получателя и сохранит его обратно в базу данных, когда сеанс промыть / закрыть. Убедитесь, что это то, что вы хотите.)

Answer 3

Нулевые объекты

Сопоставление с полями может быть полезно, если вы реализуете шаблон нулевого объекта , если ваши классы. Поскольку это не может быть выполнено (легко) при сопоставлении со свойствами. Вам в конечном итоге придется хранить поддельные объекты в базе данных.

HQL

Я не был уверен, что с HQL-запросами вам приходилось менять имена свойств, если вы использовали подход с полевым доступом. то есть, если бы у вас было <property name="FirstName" access="field.camelcase" />, я думал, что вы все еще могли бы написать "From Person where FirstName = :name";, так как он по-прежнему использовал бы имя свойства.

Дальнейшее обсуждение полевых стратегий и нулевого объекта можно найти здесь .

Производительность

Относительно производительности поля и свойства в блог Джона Чепмена Похоже, что не так много проблем с производительностью с наборами результатов малого и среднего уровня.

Таким образом, каждый подход имеет определенные льготы, которые могут быть полезны в зависимости от сценария (доступ к полям позволяет получать данные только для чтения, нет необходимости в установщиках, доступ к свойствам работает, когда от вашего poco ничего особенного не требуется, и он кажется подходом defacto. и т.д.)

Answer 4

Я сопоставляю со свойствами, потому что я использую автоматические свойства.

За исключением коллекций (например, set s. Те, которые я сопоставляю с полями (access="field.camelcase-underscore"), потому что у меня нет открытых свойств, предоставляющих их, но есть методы.

Answer 5

Я сопоставляю со свойствами, я не сталкивался с ситуацией, когда я сопоставлял бы с полем ... и когда у меня есть, я увеличивал свой B.O. дизайн для необходимости. Я думаю, что это позволяет улучшить архитектуру.

Answer 6

Я сопоставляю непосредственно с полями, что позволяет мне использовать установщики свойств для отслеживания грязного состояния свойства.

Answer 7

Я склонен согласиться с ответами выше. Как правило, сопоставьте со свойствами почти все, затем сопоставьте с полями для установщиков коллекций.
Единственное другое место, которое вы хотите сопоставить с полями, это когда у вас есть что-то:

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