注释：方法与变量

Question

I was always sure (don't know why) that it's better to add annotations to variables, but while browsing the Hibernate doc http://docs.jboss.org/hibernate/stable/annotations/reference/en/html_single/#entity-hibspec-collection I noticed they tend to annotate the methods. So should I put my annotations before methods, like this:

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

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

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

Or is it better to do it like this:

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

public long getId() { return id; }

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

Or maybe there's no difference?

Answer 1

As Péter points out, you need to pick one style and stick with it, since the style adopted for the @Id annotation will be used for everything.

Beyond that, it's simply a matter of taste. Both options work, so go for the one you prefer. Some people prefer that Hibernate injects via methods, so that they can change the implementation subtly if they need to. I prefer injecting via fields, since I find it cumbersome to have to expose all properties via getter/setter methods (7 lines vs 1 line) when in 99.9% of the times they're going to work as simple variables (and in any case I can switch the annotation style if/when I need to write custom setter functionality anyway).

There are no performance or functionality differences between the two, so choose whichever you prefer (or perhaps more importantly, whichever your team/tools prefer).

Answer 2

With the @Id annotation, there is a difference: if it is on the getter, Hibernate tries to get/set all class members via their regular getters/setters, while if it is on the member variable, Hibernate will access all the member variables directly.

In other words, you can't mix styles within the same entity.

Answer 3

It depends on the annotation.

Very generally speaking, if the entity has the standard getters/setters which match the field names then there isn't much of a difference. I tend to annotate fields when given the choice, just because I find burying the annotations down with the methods to be harder to read.

Answer 4

It's sometimes handy to be able to chose where to put them, especially when a field is not exposed publicly. It's not very common to have private getter/setter, so it's useful to be able to put annotation on the field.

It also sometimes give a bit of flexibility to play with the external/internal data representation. Here is an example that is a bit silly, but I've used a similar trick a few times ( here and here ):

@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 @... }

Generally speaking, I tend to put them on the field, I find the code more readable. But it's mostly a question of taste. The only rule to enforce is to be consitent!

Answer 5

Yeah, and i'd go against annotating stuff too much. It's nice when you're doing reflection or something like that, but i don't think that anybody wants to read annotations just because somebody thought to replace comments with them.

Answer 6

I strongly recommend use annotation on top of variables rather than using annotation on methods. This is NOT matter of taste. This is MANDATORY if you want to declare USER class which implements UserDetails from Spring Security. So following code will work and that is the only way.

@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;
    }

If you place all annotations at function getters, without mapping @OneToMany or @ManyToMany ...it will work but if you need to use those relationship then Hibernate will break. I think Hibernate already use annotation on top of variable so it doesn't like annotation of top of functions for consistent reason.

Therefore, stick to what is conventional of the framework, you won't have your codes breaks down later.