JPA Implementation Patterns: Field Access vs. Property Access
Join the DZone community and get the full member experience.
Join For Free
the jpa specification allows two ways for the persistence provider
to access the persistent state of an entity. the persistence provider
can either invoke javabeans style property accessors (getters and
setters) or access the instance fields of the entity directly. which
method is used depends on whether you have annotated the properties or
the fields of an entity.
the
jpa 1.0 specification
does not allow you to mix access types within an entity or even an
entity hierarchy. if you have annotated both fields and properties, the
behaviour is undefined. the
jpa 2.0 specification
has the
@access
annotation that makes it possible mix access types within an entity or entity hierarchy.
but the interesting question remains; which access type to use? a question that has been discussed before , but one i couldn't resist commenting on too.
- encapsulation - property access is said to provide better encapsulation, because directly accessing fields is bad, right? well actually, using property access obliges you to write getters and setters for all your persistent properties. these methods not only allow the jpa provider to set the fields, they also allow any other user of your entity class to do this! using field access allows you to write only the getters and setters you want to ( they're evil , remember?) and also write them as you want them, for example by doing validation in your setters or some calculation in your getters. in contrast, making these methods smarter when using property access is just asking for trouble .
- performance - some people prefer field access because it supposedly offers better performance than property access. but that is a very bad reason to choose field access. modern optimizing jvms will make property access perform just as fast as field access and in any case database calls are orders of magnitude slower than either field access or method invocations.
-
lazy loading in hibernate
- hibernate's lazy
loading implementation always initializes a lazy proxy when any method
on that proxy is invoked. the only exception to this is the method
annotated with the
@id
annotation when you use property access. but when you use field access
there is no such method and hibernate initializes the proxy even when
invoking the method that returns the identity of the entity. while some
propose to use property access
until this
bug
is fixed, i am not in favour of basing design decisions on framework
bugs. if this bug really hurts your performance you might want to try
and get the id of entity with the following code:
serializable id = ((hibernateproxy) entity).gethibernatelazyinitializer().getidentifier()
it's nasty, but at least this code will be localized to where you really need it.
- field access in hibernate - it is good to know that while field access is ok for hibernate to populate your entities, your code should still access those values through methods. otherwise you will fall into the first of the hibernate proxy pitfalls mentioned by my colleague maarten winkels.
to summarize i think field access is the way to go because it offers better encapsulation (without it properly managing bidirectional associations is impossible) and the performance impact is negligible (#1 on the performance problems top 10 is still the interplay between the database and your java app). the only downside are some snafu's in hibernate's lazy loading implementation that require you to take extra care when using field access.
what access type do you prefer? do you see any difference in the way field access and property access are implemented in jpa providers other than hibernate? please let me know by leaving a comment below. see you at the next jpa implementation patterns blog in which i will talk about mapping inheritance hierarchies in jpa.
Opinions expressed by DZone contributors are their own.
Comments