何时使用注解

何时使用注解

作者:Bill Burke

翻译：于涛

不同于实事的是，我们更多的编写可以实现逻辑变化的ejb之外。我一直在想，何时及何地XML可以更多的使用注解，以及在什么情况下，注解可以更多的使用XML。

所以，我提出了这样一些规则：

1如果你正在应用元数据（metadata）改变类的设计时候，使用注解

2如果你的元数据（metadata）改变了你的代码设计并且与你的类相结合，使用注解

3 在于应用服务器或者数据库之间，如果你的应用需要轻量级的话，请不要使用注解。因为那样会变得很多余。

4 当你想配置部署的每一个步骤的时候，请使用XML。（当你想以单步配置方式去配置的时候）

所以呢，现在让我们做一个很小的练习，在这个过程中去了解ejb3.0的注解。首先让我们从会话Bean(Session bean)开始

@Stateless,@Stateful
我们说，这里来应用我们的规则一。这里你需要非常清楚的是，你的ejb在工作的时候，是有状态会话bean(Stateful Session bean)还是无状态会话bean(Stateless Session bean)。如果从这一点上来说的话，这是显而以见的，我们要使用注解。
@Remote,@Local
我们回去在看一下那四条规则，这里好像是应用了我们的规则4.从语以上理解这些接口的调用关系,这是我们要清楚的一点。那么我们说远程接口（@Remote inferface）的重心是访问值。本地接口的重心是访问引用。我们仅仅是通过这些接口的定义，现在你可能想知道是,在你的应用代码中真正应用哪些接口。

@TransactionAttribute
规则一定义了@TransactionAttribute的应用。在上下文的事务当中，无论你的代码是调用了还是没有调用，通常都影响你类的设计。举个例子来说吧，如果你的应用没有在事务中的话，那么你将不能连接你的实体管理服务(EntityManager service)。我不认为这里应用了规则三，因为在部署的过程中，你的代码设计可能将依懒于这些事务，但是你可能又不想让部署的人去改变你的事务边界。@TransactionAtrribute看上去就像是一个非常好的候选人一样，永远被人支持。

安全注解（Security annotations）
对于安全注解，我认为这里应用了规则4。规则一并没有在这里被应用，因为安全注解对于会话bean(Session bean)的设计是不起作用的。规则三在这里也不能被应用,因为你的应用将是轻量级的，但是你可能想配置安全的每一个步骤。那么，在于JAR包建立完成后，你将用多长时间去改变一次你的XML DDs？多长时间人们去真正的修改一次XML DDs呢？

Persistence
首先这是一个纯粹的实体bean(Entity bean)注解。@OneToOne,@oneToMany,@ManyToOne,@ManyToMany,@Basic,@Serialized,@Transient。这些关系注解所能得到的信息是两个bean之间的关系与方向.当你去建立或者去合并这些bean的时候，这些关系将影响你去编写你bean的代码。The FetchType tells you whether or not the property will be lazily loaded or not. 这些代码将会与你的bean结合执行,一个查询可能将以"fetch"作为关键字它将预载着这个关系。@Transient是非常重要的。因为不管是什么访问，你都需要知道是不是在你的查询里。在@PostLoad回调（callback）方法中，@Tansient属性可能同样有什么操作需要初始化。所以我认为，在这里所有的所有，可以被归入规则一和规则二。

那么关于表和列的映射问题呢？如果你不使用自动产生表，那么规则三在这里就不适用。表和列的名字在数据库里面是轻量级的。如果你想应用规则三的话，那么你要使用一些如@Column.columnDefinition或者@Lob(有些数据库不在支持blobs和clobs)这样的注解。

@Entity public class Customer {

@Id(generate="PLUGGABLE_GENERATOR") long pk;

}

那么规则四可以用在表的映射上面吗？答案当然是可以了。同样的类就需要在多种O/R映射为不同的遗留系统和数据库.

结论
这些看上去就像Session/MDBs，当持久化不是很重要的时候，注解可能更加倾向于XML。如果我们要考虑持久化的问题时，那么一般化的问题就可以使用注解，但是要除了主键（primary-key）产生的定义和你的类要映射更多关系的结构。注解也是很精彩的,当你不在继续引用冗长的XML文档去配置你要持久化的对像,你的工具就可以从关系列表里产生出来代码。为了框架，注解不仅仅是为了描述元数据，但是也是承认的是，它同样也是文档的一部分。我记Gavin在NEJug里说过这话。

@OneToMany(mappedBy="item")

Collection<Bid> getBids() {...}

is much less verbose than

/**

* This is a OneToMany relationship to the Bids class. It is also

* bidirectional with the owning side of the relationship being maintained

* by the "item" property on the Bid class

*/

Collection<Bid> getBids() {...}