Аннотации: методы против переменных

Question

Я всегда был уверен (не знаю почему), что лучше добавлять аннотации к переменным, но при просмотре документа Hibernate http://docs.jboss.org/hibernate/stable/annotations/reference/en/html_single/#entity-hibspec-collection я заметил, что они имеют тенденцию комментировать методы. Так что я должен поставить свои аннотации перед методами, как это:

@Entity
public class Flight implements Serializable {
private long id;

@Id @GeneratedValue
public long getId() { return id; }

public void setId(long id) { this.id = id; }
}  

Или лучше сделать это так:

@Entity
public class Flight implements Serializable {
@Id @GeneratedValue
private long id;

public long getId() { return id; }

public void setId(long id) { this.id = id; }
}  

Или, может быть, нет никакой разницы?

Answer 1

Как отмечает Петер, вам нужно выбрать один стиль и придерживаться его, поскольку стиль, принятый для аннотации @Id, будет использоваться для всего.

Кроме того, это просто вопрос вкуса. Оба варианта работают, так что выбирайте тот, который вы предпочитаете. Некоторые люди предпочитают, чтобы Hibernate внедрял с помощью методов, чтобы они могли тонко изменить реализацию, если им это необходимо. Я предпочитаю делать инъекции через поля, так как считаю трудным выставлять все свойства методами getter / setter (7 строк против 1 строки), когда в 99,9% случаев они будут работать как простые переменные (и в любом случае Я могу поменять стиль аннотации, если / когда мне все равно нужно написать пользовательские функции установщика).

Между этими двумя показателями нет различий в производительности или функциональности, поэтому выбирайте, какой вы предпочитаете (или, что еще важнее, какой предпочитает ваша команда / инструменты).

Answer 2

С аннотацией @Id есть различие: если он находится на получателе, Hibernate пытается получить / установить всех членов класса через их обычные средства получения / установки, в то время как если он находится на переменной-члене, Hibernate получит доступ все переменные-члены напрямую.

Другими словами, вы не можете смешивать стили внутри одной и той же сущности.

Answer 3

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

Это также иногда дает немного гибкости, чтобы играть с внешним / внутренним представлением данных.Вот пример, который немного глуп, но я несколько раз использовал подобный трюк ( здесь и здесь ):

@Column(...)
private String email;

public String getAlias() { ... split email and return the part before @ ... }
public void setAlias( String alias ) { ... change the part before the @ ... }

public String getHost() { ... split email and return the part after @ ... }
public void setHost(String host) { ... change the part after the @... }

Вообще говоряЯ склонен ставить их на поле, я нахожу код более читабельным.Но это в основном вопрос вкуса.Единственное правило, которое нужно соблюдать, это быть последовательным!

Answer 4

Зависит от аннотации.

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

Answer 5

Я настоятельно рекомендую использовать аннотацию поверх переменных, а не аннотацию для методов. Это НЕ вопрос вкуса. Это ОБЯЗАТЕЛЬНО, если вы хотите объявить класс USER, который реализует UserDetails из Spring Security. Таким образом, следующий код будет работать, и это единственный способ.

@Entity
class User implements UserDetails {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    @OneToMany
    private List<UserRole> roles;

    //....Setters and Getters..........
    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        return null;
    }

    @Override
    public boolean isAccountNonExpired() {
        return false;
    }

    @Override
    public boolean isAccountNonLocked() {
        return false;
    }

    @Override
    public boolean isCredentialsNonExpired() {
        return false;
    }

    @Override
    public boolean isEnabled() {
        return false;
    }

Если вы разместите все аннотации в функциях получения, без отображения @OneToMany или @ManyToMany ... это будет работать, но если вам понадобится использовать эти отношения, то Hibernate будет нарушен. Я думаю, что Hibernate уже использует аннотацию поверх переменной, поэтому он не любит аннотацию вершины функций по непротиворечивой причине.

Следовательно, придерживайтесь того, что является обычным для фреймворка, у вас не будет кодов позже.

Answer 6

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