Будьте в спящем режиме Аннотации - Который лучше, поле или доступ свойства?

Обычно бобы являются POJO, таким образом, у них есть средства доступа так или иначе.

, Таким образом, вопрос не, "какой лучше?", но просто, "когда использовать доступ к полю?". И ответ, "когда Вам не нужен метод set/метод get для поля!".

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

А быстрый обзор через Google предполагает, что доступ к полю является большинством (например, http://java.dzone.com/tips/12-feb-jpa-20-why-accesstype ).

я полагаю, что доступ к полю является идиомой, рекомендуемой Spring, но я не могу найти, что ссылка создает резервную копию этого.

существует связаны ТАК вопрос , который попытался измерить уровень и пришел к выводу, что нет "никакого различия".

Это действительно зависит от конкретного случая - обе опции доступны по причине. IMO это сводится к трем случаям:

1. метод set имеет некоторую логику, которая не должна быть выполнена во время загрузки экземпляра от базы данных; например, некоторая проверка значения происходит в методе set, однако данные, прибывающие из дб, должны быть допустимыми (иначе, это не добралось бы там (:); в этом случае доступ к полю является самым соответствующим;
2. метод set имеет некоторую логику, которая должна всегда вызываться, даже во время загрузки экземпляра от дб; например, инициализируемое свойство используется в вычислении некоторого вычисляемого поля (например, свойство - денежная сумма, расчетное свойство - в общей сложности несколько денежных свойств того же экземпляра); в этом случае требуется доступ свойства.
3. Ни один из вышеупомянутых случаев - тогда обе опции применимы, просто остаются последовательными (e.i., если доступ к полю является выбором в этой ситуации, тогда используют все это время в аналогичной ситуации).

I think annotating the property is better because updating fields directly breaks encapsulation, even when your ORM does it.

Here's a great example of where it will burn you: you probably want your annotations for hibernate validator & persistence in the same place (either fields or properties). If you want to test your hibernate validator powered validations which are annotated on a field, you can't use a mock of your entity to isolate your unit test to just the validator. Ouch.

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

Рассматривают следующие отображения для 2 основных бобов:

<hibernate-mapping package="org.nkl.model" default-access="field">
  <class name="FieldBean" table="FIELD_BEAN">
    <id name="id">
      <generator class="sequence" />
    </id>
    <property name="message" />
  </class>
</hibernate-mapping>

<hibernate-mapping package="org.nkl.model" default-access="property">
  <class name="PropBean" table="PROP_BEAN">
    <id name="id">
      <generator class="sequence" />
    </id>
    <property name="message" />
  </class>
</hibernate-mapping>

И следующие модульные тесты:

@Test
public void testFieldBean() {
    Session session = sessionFactory.openSession();
    Transaction tx = session.beginTransaction();
    FieldBean fb = new FieldBean("field");
    Long id = (Long) session.save(fb);
    tx.commit();
    session.close();

    session = sessionFactory.openSession();
    tx = session.beginTransaction();
    fb = (FieldBean) session.load(FieldBean.class, id);
    System.out.println(fb.getId());
    tx.commit();
    session.close();
}

@Test
public void testPropBean() {
    Session session = sessionFactory.openSession();
    Transaction tx = session.beginTransaction();
    PropBean pb = new PropBean("prop");
    Long id = (Long) session.save(pb);
    tx.commit();
    session.close();

    session = sessionFactory.openSession();
    tx = session.beginTransaction();
    pb = (PropBean) session.load(PropBean.class, id);
    System.out.println(pb.getId());
    tx.commit();
    session.close();
}

Вы будете видеть тонкое различие в требуемых выборах:

Hibernate: 
    call next value for hibernate_sequence
Hibernate: 
    insert 
    into
        FIELD_BEAN
        (message, id) 
    values
        (?, ?)
Hibernate: 
    select
        fieldbean0_.id as id1_0_,
        fieldbean0_.message as message1_0_ 
    from
        FIELD_BEAN fieldbean0_ 
    where
        fieldbean0_.id=?
0
Hibernate: 
    call next value for hibernate_sequence
Hibernate: 
    insert 
    into
        PROP_BEAN
        (message, id) 
    values
        (?, ?)
1

таким образом, звоня fb.getId() требует выбора, тогда как pb.getId() не делает.

Я думаю об этом и выбираю метод доступа

почему?

потому что аксессуар для поля и метамфетаминов один и тот же. но если позже мне понадобится какая-то логика в поле загрузки, я сохраню все аннотации, помещенные в поля

regards

Grubhart

У меня был тот же вопрос относительно типа доступа в спящем режиме, и я нашел несколько ответов здесь .

Я предпочитаю и использую аксессоры свойств:

• Я могу добавить логику, если возникнет необходимость (как указано в принятом ответе).
• это позволяет мне вызывать foo.getId () без инициализации прокси (важно при использовании Hibernate, пока не будет разрешено HHH-3718 ).

Недостаток:

• это делает код менее читаемым, вам, например, нужно просмотреть весь класс, чтобы увидеть, есть ли там @Transient .

Вот ситуация, в которой вам НЕОБХОДИМО использовать аксессоры свойств. Представьте, что у вас есть абстрактный класс GENERIC с большим количеством реализаций, которые можно унаследовать в 8 конкретных подклассах:

public abstract class Foo<T extends Bar> {

    T oneThing;
    T anotherThing;

    // getters and setters ommited for brevity

    // Lots and lots of implementation regarding oneThing and anotherThing here
 }

Теперь, как именно вы должны аннотировать этот класс? Ответ: ВЫ НЕ МОЖЕТЕ аннотировать его ни полем, ни свойством, потому что вы не можете указать целевую сущность на данном этапе. Вы ДОЛЖНЫ аннотировать конкретные реализации. Но поскольку сохраняемые свойства объявлены в этом суперклассе, вы ДОЛЖНЫ использовать доступ к свойствам в подклассах.

Доступ к полям не является вариантом в приложении с абстрактными общими суперклассами.