Вы не инициализировали свои текстовые просмотры counter1 и counter2. Инициализируйте обе переменные перед вызовом для них методов.
Я предпочитаю средства доступа, так как я могу добавить некоторую бизнес-логику в свои средства доступа всякий раз, когда мне нужно. Вот пример:
@Entity
public class Person {
@Column("nickName")
public String getNickName(){
if(this.name != null) return generateFunnyNick(this.name);
else return "John Doe";
}
}
Кроме того, если вы добавите в микс еще одну библиотеку (например, какую-нибудь библиотеку JSON-конвертирующую или BeanMapper или Dozer или другую библиотеку для преобразования / клонирования bean-компонентов, основанную на свойствах getter / setter), у вас будет гарантия, что lib синхронизируется с диспетчером персистентности (оба используют геттер / сеттер).
Обычно бобы являются POJO, таким образом, у них есть средства доступа так или иначе.
, Таким образом, вопрос не, "какой лучше?", но просто, "когда использовать доступ к полю?". И ответ, "когда Вам не нужен метод set/метод get для поля!".
Я предпочитаю доступ к полю, потому что тот путь я не вынужден предоставить методу get/методу set для каждого свойства.
А быстрый обзор через Google предполагает, что доступ к полю является большинством (например, http://java.dzone.com/tips/12-feb-jpa-20-why-accesstype ).
я полагаю, что доступ к полю является идиомой, рекомендуемой Spring, но я не могу найти, что ссылка создает резервную копию этого.
существует связаны ТАК вопрос , который попытался измерить уровень и пришел к выводу, что нет "никакого различия".
Это действительно зависит от конкретного случая - обе опции доступны по причине. IMO это сводится к трем случаям:
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
}
Теперь, как именно вы должны аннотировать этот класс? Ответ: ВЫ НЕ МОЖЕТЕ аннотировать его ни полем, ни свойством, потому что вы не можете указать целевую сущность на данном этапе. Вы ДОЛЖНЫ аннотировать конкретные реализации. Но поскольку сохраняемые свойства объявлены в этом суперклассе, вы ДОЛЖНЫ использовать доступ к свойствам в подклассах.
Доступ к полям не является вариантом в приложении с абстрактными общими суперклассами.