Frank and I collected some Hibernate tips, and we named them with some sexy names ;-) This afternoon I tried to replace hibernate by JSR220 persistent API in a typical web application, and I found some new tips in JSR220 Persisntent API (Frank, I'm here waiting your names).
btw: I'm a believer in Peter Coad's Color Modeling approach, all the following tips are modeled in the approach. I recommend you the greate book 'Java Modeling in Color with UML' if you'd no idea about the Color UML.
1. Annotating Description with @Embeddable, and the Thing it describe with @Entity
Take Product and ProductDescription for example.
1
@Embeddable
2
class ProductDescription 
{
3
private String name;
4 private String description;
5 . and getters and setters
6
}
7
8@Entity(access = AccessType.FIELD)
9class Product {
10
11 private ProdcutDescription description;
12
13}
14
In hiberante, we could make the ProductDescription as an embedded persistent object of Product via the component tag.If the ProductDescription should be embedded in another object, we've to declare it once more.
Things become more convenient in JSR 220, because non-transite fields, whose class is annoated with @Embeddable, are treated as embedded persistent objects automatically, we'd have fine-grained persistent objects without long-winded config file.
2.Avoiding Database Field in Domain Model Using @AttributeOverride
It's claimed that Annotaton could simplify development, but considering the cost of hard-coding mapping information in source codes I prefer some other complicated ways.It's too ugly to write code like following.
1@Entity(access = AccessType.FIELD)
2@Table(name="TAB_PRODUCT")
3class Product {
4
5 @Basic
6 @Column(name="NAME", nullable=false, length=512)
7 private String name;
8}
It's sucks but could be avoided.
1@EmbeddableSuperclass
2class Product {
3
4 @Basic
5 private String name;
6}
7
8@Entity
9@AttributeOverride(name="name", column=@Column(name="Name"))
10@Table(name="TAB_PRODUCT")
11class PersistentProduct extends Product {
12}
We could separate the domain model and the persistent model by inheritance.Although we could do the same thing in hiberante too, we have to provide lots of configuration files.Once more we'd have hierachical persistent objects without long-winded config file.
3.Avoiding Database Primary Key in Domain Model
In most O/R mapping framework, we are always asked to give a primary key or identifier to our domain model, and we are suggested using meanless identifier instead of domain-specified identifer.It's kinda of Domain Pollution.Although we couldmake the domain model more clearer via inheritance, it's pointless for common usages.
Fortunately, we HAVE TO separate domain model and persistent model(as above mentioned), so that we can throw this bad habit away conviniently :D
1@EmbeddableSuperclass
2class Product {
3}
4
5@Entity
6class PersistentProduct extends Product{
7
8 @Id private long primaryKey;
9}
Conclusion
After two hours walking around JSR220 persistent API, I figured out that JSR220 mixed ugly into convenience... and it's quite easy to write ugly codes in jsr220...so that we've to insist on using OO and the convenience jsr220 provided to make our domain model as clear as possible.
Although JSR220 is more ugly than hibernate, we could get clearer domain model in jsr220 rather than hibernate, because we could not stand the unly in jsr220...weird way to make us keeping more OO...cool isn't it...