当前页面: 开发资料首页 → J2EE 专题 → 轻量级的关系/对象映射--Amber进阶
轻量级的关系/对象映射--Amber进阶
摘要: 本文推荐的一个叫Amber的框架提供了一种相反的轻量级实现。这种实现利用Java注解(annotations)来管理JavaBeans的CRUD周期(Create Read Update Delete)。事务处理被交还给数据库，而XML映射描述符则被注解代替。本文所面向的读者是那些对不使用XML描述符来有效操纵数据库感兴趣的Java中级开发者。
版权声明：任何获得Matrix授权的网站，转载时请务必保留以下作者信息和链接
作者:Norbert Ehrekedeafwolf(作者的blog:http://blog.matrix.org.cn/page/deafwolf)
原文:http://www.matrix.org.cn/resource/article/44/44381_Amber+Object+Mapping.html
关键字:relational;mapping;Amber
动机
普通O/R映射框架是非常强大的；但是在介绍如何设计和部署时，一些问题却很少被提及。我们将列出这些缺点，并针对这些问题来演示一个叫Amber的框架。
1. OO驱动的数据模型导致了过于简单的ER模型。
2. XML描述符使得维护困难。
3. 在O/R层进行事务处理非常困难。
4. 现有框架的学习曲线相对陡峭。
在两种模型之间交换数据，比如ER模型和OO模型，必须克服所谓的阻抗不匹配。对于大多数O/R模型工具来说，对象模型处于支配地位。大体上，这意味着Java持久层负责从现有的对象模型生成ER模型。这个主意非常引人注目，因为当商务模型确定以后，开发团队就再也不需要担心持久化的问题了。
对于常规的O/R工具而言，ER模型是一个结果，一个产物，顶多是一个容器。而商务过程实际上是按ER模型设计的，这就导致了两者之间的不协调。这样的话，ER模型的调整就非常困难，甚至是不可能的，因为O/R框架可能会在任何时候重构ER模型。同样，当商务过程发生改变时，O/R域的调整会自动重构ER域，于是ER模型变得令人费解，并且有时性能会下降到临界点。
还有另一个问题。会被持久化的类需要在外部XML描述(映射)文件中部署。初看不错，但是当我们处理现存的系统时，这很快就成了烦人的事。只要发生了一点变动，就得有不只一个地方需要修改，也就是源代码和映射文件。
最后，现有的O/R框架是为了处理事务而设计的。综合来看，这不是必须的，因为存储容器(例如关系数据库)是非常傻的容器。尽管我们不得不进行事务处理，但那并不是我们想要的。这些应该是数据库的事。
介绍Amber
Amber从相反的角度来解决数据交换的问题。它采用ER模型为参考来确立OO结构。它还采用存储过程作为数据库访问主要方式，存储过程提供了访问数据库的唯一途径，并且完全的建立起事务处理机制。最后中间层会被实现为一系列存储过程的集合。这意味着ER模型的专家，数据库管理员要负责设计和优化包括存储过程在内的一系列问题，于是比起自动创建的系统，新的系统能够拥有更好的结构，更快的速度和更安全的访问。因此，许多难题迎刃而解。
• 事务能够(或者说应该)被封装进存储过程。
• 读操作仅返回结果集合。
• 写操作只需要调用存储过程，而不是在Java代码中嵌入SQL。
• 使用存储过程，就不会因为SQL注入而导致安全漏洞。
当然，这意味着通常在Java代码中处理的事被转移到存储过程中了。这样不会有人犯错了。这对Java开发者来说有莫大的好处。
映射
Amber的核心在于，不管被提交到数据库的查询是什么，查询结果都是一列Java对象。当然，这是从Java开发者的角度来看的。那么剩下的问题只是把字段映射到对象的属性。以及在把数据写入数据库时，把Java对象的属性映射到存储过程的参数。
Amber把结果集映射到JavaBean，并用相同的机制在增删改时把bean的内容映射到参数。对于JavaBean的相关信息和定义，请查看资源那一段。
这种做法用到了Java语言的新特性，这个叫做注解的特性是从J2SE 5.0开始使用的。
注解，在JSR 175中也叫做“元数据”，是一种辅助代码,可以用来提供类，方法，属性的详细信息。在Javadoc API中，元数据本来是为了用来内联文档的。所以，在不干扰正常代码的前提下，注解可以用来描述代码的具体作用。如果你想知道关于注解更多的信息以及作用，请参考Tiger: A Developer's Notebook，或者看看我写的一篇更有趣的文章" Annotations to the Rescue"。
一步一步来
我们来解决一个小的持久化问题。从数据库读取一列Jedi对象，我们假设返回的结果集看起来像下面的表格。请注意，我们接下来的讨论并不依赖于这些表格，尽管这些例子实际上都是基于这些表格的。一般来说，我们得到的表列数据是通过使用少量的SQL连接多个表或者视图来得到的。(当然，先向星球大战的爱好者们告罪。)
我们先定义一个叫Jedi的简单类。
public class Jedi {
private Integer _id;
private String _name;
private Double _forceRating;
private Integer _age;
private Boolean _alive;
@ColumnAssociation(name="jedi_id")
public void setId( Integer id ) {
_id = id;
}
@ColumnAssociation(name="name")
public void setName( String name ) {
_name = name;
}
@ColumnAssociation(name="force_rating")
public void setForceRating( Double fr ) {
_forceRating = fr;
}
@ColumnAssociation(name="age")
public void setAge( Integer age ) {
_age = age;
}
@ColumnAssociation(name="alive")
public void setAlive( Boolean alive ) {
_alive = alive;
}
@ParameterAssociation(name="@jedi_id",
index=0, isAutoIdentity=true)
public Integer getId() {
return _id;
}
@ParameterAssociation(name="@name", index=1)
public String getName() {
return _name;
}
@ParameterAssociation(name="@force_rating",
index=2)
public Double getForceRating() {
return _forceRating;
}
@ParameterAssociation(name="@age", index=3)
public Integer getAge() {
return _age;
}
@ParameterAssociation(name="@alive", index=4)
public Boolean getAlive() {
return _alive;
}
}这里发生了什么？你在类中看到getter和setter方法上面有两种注解。
注解@ColumnAssociation用来把JavaBean中的setter方法和结果集中的一个字段连接起来，这样从数据库中得到的表列数据就能够被Amber 写入bean的属性里。注解@ColumnAssociation只适用于setter方法，因为Amber使用这些注解以及从数据库中读取的相应值来寻找和调用那些方法。
同样，getter方法需要@ParameterAssociation注解来把JavaBean的属性和调用增删改操作时的参数连接起来。这个注解只适用于getter方法，因为Amber使用getter方法来把值填到参数里。因为JDBC的缘故，需要提供参数的索引。这个也许的多余的，取决于数据库以及存储过程是否需要，不过为了完整性，以及遵循JDBC API规范，最好还是提供一下。
必须提供一个无参数的构造函数，因为这个类会被自动构造(通过反射)。在上面的类中，没有无参数构造函数是允许的，因为我们没有提供其他的构造函数，但是当我们增加了额外的构造函数时，就必须提供一个明确的给Amber。
这个JavaBean的作用是从数据库里读出数据以及写回数据库。完全不需要外部的描述文件。注意，我们也可以用这种方式建立任何类，不只是JavaBean。
你也许会奇怪：为什么用注解？为什么不是像JavaBean那样通过属性名来隐式关联？我们这么做，是为了让我们的设计保持一定的自由度。换句话说，我们的Java代码不需要依赖于ER模型设计的字段名。如果你已经习惯于操作表，你也许不同意这点，但是当你使用的存储过程里需要连接表和视图时，你就不得不使用别名。
Amber的连接器和JDBC
在我们开始读写数据库之前，我们需要与数据库建立连接。Amber使用一个Connector来访问数据库。简单说来，这就是把数据库驱动和连接字符串结合使用而已。在应用中，我们使用一个ConnectorFactory来管理可用连接。像下面的代码那样，我们使用一个本地的type-4驱动来初始化一个到SQL server的连接。我们假设服务器的名字是localhost，数据库的名字是jedi，用户名是use，密码是theforce，为了简单一点，我在下面的代码中省略了全部的异常处理。
String driverClassName =
"com.microsoft.jdbc.sqlserver.SQLServerDriver";
String url =
"jdbc:microsoft:sqlserver://" +
"localhost;databasename=jedi;" +
"user=use;pwd=theforce";
Amber's Connector is associated with a String, alias under which it remains accessible from the ConnectorFactory. Here, we're going to use the alias starwars.
Amber的Connector使用一个String作为别名来从ConnectorFactory获取连接，接下来，我们将使用别名starwars。
ConnectorFactory.getInstance().add(
"starwars", driverClassName, url
);
因为Connector是对JDBC连接的轻量级封装，所以我们可以像以前一样操作这个连接。
读取
封装在Connector外面的是一个BeanReader对象，它需要一个Connector和一个Class来告诉reader从数据库读出的bean是什么类型的。现在读取一列Jedi对象就只需要下面几行了。
Connector connector =
ConnectorFactory.createConnector( "starwars" );
BeanReader reader =
new BeanReader( Jedi.class, connector );
CollectionjediList =
reader.executeCreateBeanList(
"select * from jedi"
);
这段代码使用了一种叫泛型的新特性，这种特性是从J2SE 5.0开始使用的。Collection声明的那行代码表明jediList一律由Jedi类型的对象组成。编译器在这里会发出警告，reader只有在运行时刻才知道会产生什么类型的对象。因为在J2SE 5.0中，泛型在执行的时候会把类型信息抹掉，所以可能导致不安全的类型转换。非常遗憾的，因为同一原因，我们不能把BeanReader写成BeanReader
那么复合结构会如何呢？好吧，我们有几种方法可以处理这个问题。比如，我们在Jedi和Fighter (例如，每个Jedi有好几艘太空战斗机)之间有一个一对多的关系。在数据库中，Fighter的数据看起来像下面那样。
换句话说，Luke有两艘战斗机(X-和B-Wing)，Yoda则拥有一艘Star Destroyer，而Obi Wan已经死掉了。
数据之间的关系在OO域中有几种方法可以模型化。我们只挑选最简单的那种。所以我们需要Jedi类可以拥有一组Fighter对象作为成员。下面的Fighter类是为了让Amber使用而建立的。
public class Fighter {
private Integer _id;
private Integer _jediId;
private String _name;
private Double _firepowerRating;
private Boolean _turboLaserEquipped;
@ColumnAssociation(name="fighter_id")
public void setId( Integer id ) {
_id = id;
}
@ColumnAssociation(name="jedi_id")
public void setJediId( Integer jediId ) {
_jediId = jediId;
}
@ColumnAssociation(name="name")
public void setName( String name ) {
_name = name;
}
@ColumnAssociation(name="firepower_rating")
public void setFirepowerRating( Double firepowerRating ) {
_firepowerRating = firepowerRating;
}
@ColumnAssociation(name="turbo_laser_equipped")
public void setTurboLaserEquipped(
Boolean turboLaserEquipped ) {
_turboLaserEquipped = turboLaserEquipped;
}
@ParameterAssociation(name="@fighter_id",
index=0,isAutoIdentity=true)
public Integer getId() {
return _id;
}
@ParameterAssociation(name="@jedi_id",index=1)
public Integer getJediId() {
return _jediId;
}
@ParameterAssociation(name="@name",index=2)
public String getName() {
return _name;
}
@ParameterAssociation(name="@firepower_rating",
index=3)
public Double getFirepowerRating() {
return _firepowerRating;
}
@ParameterAssociation(name="@turbo_laser_equipped",
index=4)
public Boolean getTurboLaserEquipped() {
return _turboLaserEquipped;
}
}下面的是改进后的Jedi类。它新增加了一个List
public class Jedi {
private Integer _id;
private String _name;
private Double _forceRating;
private Integer _age;
private Boolean _alive;
private ArrayList _fighterList =
new ArrayList();
@ColumnAssociation(name="jedi_id")
public void setId( Integer id ) {
_id = id;
}
@ColumnAssociation(name="name")
public void setName( String name ) {
_name = name;
}
@ColumnAssociation(name="force_rating")
public void setForceRating( Double forceRating ) {
_forceRating = forceRating;
}
@ColumnAssociation(name="age")
public void setAge( Integer age ) {
_age = age;
}
@ColumnAssociation(name="alive")
public void setAlive( Boolean alive ) {
_alive = alive;
}
@ParameterAssociation(name="@jedi_id",
index=0, isAutoIdentity=true)
public Integer getId() {
return _id;
}
@ParameterAssociation(name="@name", index=1)
public String getName() {
return _name;
}
@ParameterAssociation(name="@force_rating",
index=2)
public Double getForceRating() {
return _forceRating;
}
@ParameterAssociation(name="@age", index=3)
public Integer getAge() {
return _age;
}
@ParameterAssociation(name="@alive", index=4)
public Boolean getAlive() {
return _alive;
}
public ArrayList getFighterList() {
return _fighterList;
}
public void setFighterList( ArrayList fighterList ) {
_fighterList = fighterList;
}
} 从数据库读取Jedis的代码看起来像下面这样：
Connector connector =
ConnectorFactory.getInstance().createConnector( "starwars" );
BeanReader jediReader =
new BeanReader( Jedi.class, connector );
BeanReader fighterReader =
new BeanReader( Fighter.class, connector );
CollectionjediList =
reader.executeCreateBeanList( "select * from jedi" );
for( Jedi jedi : jediList ) {
String query =
"select * from fighter where jedi_id = " + jedi.getId();
Collectionfighters =
fighterReader.executeCreateBeanList( query );
jedi.setFighterList(
new ArrayList( fighters ) );
}
瞧，这就是Jedi们拥有的战斗机了。请注意，我们并没有敲出把Fighter读进Jedi的代码。因为Jedi和Fighter会严格的匹配。你会说上面的代码在依赖注入模式中只是一些部件。也许我是在说大话，我只想说：把互相依赖的东西分开，并且使分布在各处的代码共同工作。如果你想在这方面知道得更多，请看Martin Fowler的"Inversion of Control Containers and the Dependency Injection pattern"。
写入
现在，该写入了。把改变了的Jedi写入数据库只需要下面几行代码。
Connector connector =
ConnectorFactory.getInstance().createConnector( "starwars" );
BeanWriter writer =
new BeanWriter( Jedi.class, connector );
writer.executeStringUpdate(
sampleBean, "UpdateJedi" );
这里，数据库访问通过生成SQL查询字符串。最下面一行代码生成执行字符串并发送到数据库，修改了使用1000作为id的Jedi(就是Obi Wan)的状态(假设我们把属性alive改为true，把forceRating改为6.0)。
UpdateJedi
@name='Obi Wan Kenobi', @jedi_id=1000,
@alive=1, @force_rating=6.0, @age=30
如果你想建立一个新的Jedi，我们只需要简单的构造一个新的Jedi并用下面的代码写入数据库。
Jedi newJedi = new Jedi();
newJedi.setName( "Mace Windu");
newJedi.setAge( 40 );
newJedi.setAlive( false );
newJedi.setForceRating( 9.7 );
Connector connector =
ConnectorFactory.getInstance().createConnector( "starwars" );
BeanWriter writer =
new BeanWriter( Jedi.class, connector );
writer.executeStringInsert(
newJedi, "InsertJedi" );
你会注意到，我们使用了不同的方法和存储过程来写入数据。最后字符串会是这样。
InsertJedi
@name='Mace Windu', @alive=0,
@force_rating=9.7, @age=40
发生了什么？我们假设属性jediId是由数据库自动生成的。实际上，在上面定义的Jedi类中，我们指定@ParameterAssociation的属性isAutoIdentity=true来达成这一点。因为数据库会给bean提供主键，所以参数@jedi_id就省略了。
这里需要注意一下。因为jediId是由数据库提供的，所以这个数据一定会通过存储过程InsertJedi传回数据库。随后，方法executeStringInsert返回一个JDBC的ResultSet，用来返回ID或者刚插入的数据行。这个信息可以手动处理，不过Amber提供了辅助函数来把新的ID注入到新对象中。
比起操作的透明度，读写时使用字符串来处理的类型安全问题更容易让人担心。因为把参数转化成字符串后，类型信息就丢失了。然而，这种技术有一个很大的优势：任何查询字符串都会被记录下来，数据库管理员可以通过分析来找出错误原因，并且准确知道应用调用了什么或者从数据库查询了什么。这种类型的透明使得调试更加容易。
如果Jedi的战斗机列表改变了，还是手动更新数据库比较好。取决于Fighter列表发生的变化，比较粗鲁的做法是删除这个Jedi的全部战斗机列表，然后把新的列表写回数据库中。假设我们手里有一个jedi对象和一列新的Fighter对象，我们接下来需要把新列表写进fighters中。更进一步，我们假设通过存储过程InsertFighter把一个新的Fighter对象写进数据库。
Connector connector =
ConnectorFactory.createConnector( "starwars" );
BeanWriter writer =
new BeanWriter( Fighter.class, connector );
connector.execute(
"delete from fighters where jedi_id = " + jedi.getId() );
for( Fighter fighter : fighters ) {
fighter.setJediId( jedi.getId() );
connector.executeStringInsert(
fighter, "InsertFighter" )
}
这段代码处理一整套的执行字符串，每个字符串中的name分别对应着fighters表中的fighter：
InsertFighter @jediId=..., @name="...";
你也许注意到了，这个方法并没动用事务。像上面说的那样，这里并没使用异常处理，如果delete操作失败了，会产生一个SQLException，而后面的循环根本不会被执行。可是如果是其他情况呢？比如接下来的InsertFighter调用出错了呢？这时事务是必须的，最好把操作放在存储过程里面。如果我想在事务中从Fighter对象获取全部参数以及Jedi ID并处理“新”战斗机呢？这个话题值得在另一篇文章中讨论。
局限和缺点
像任何工具或者技术一样，我们讨论的方法具有一定的局限性。
• 因为不使用XML描述符，所以当数据库和对象域之间的接口发生改变时，就会出问题。实际上，当改变只发生在名字而不是类型时，或者没有属性/字段增减时，使用XML描述符比Amber好一点。如果不是上述情况，两种系统都需要重新编译和部署。
• 复合管理不是自动化的。事实上，当你比较Amber和大的O/R框架时，你会发现有很多东西都不是自动化的。在把数据库作为哑存储设备或者用表连接中间层的商业设定中，Amber并没有太大的用处。另一方面，你可以说Amber适合依赖注入风格的设计，以及数据之间的松耦合，这通常认为比隐式依赖要好。
• 最后，注解分析以及自省机制的运行开销比较大。在一个与数据库有大量交互(比如，一个用于并发用户交互的中间件)而不是单用户或者少量用户偶尔交互的系统中，Amber会导致性能问题。
结论
这篇文章示范了一种相对于传统的O/R映射相反的R/O映射。所谓的面向对象和关系系统之间的阻抗不匹配，在把关系数据模型定义成对象域的引用模型，以及使用存储过程这一工具来操作数据库(尤其是写操作)之后，这个复杂的映射任务被简化了。这种映射是通过注解这种Java 1.5的新语言特性来实现的。我们通过Amber框架来支持和演示了这种方法。
Amber是一个小型框架，易于学习和使用。只需要处理几个非常接近JDBC的类。数据库和JavaBean之间的连接通过注解来实现，不需要任何XML描述符，因为XML对人来说可读性不高。而数据库和应用之间的映射也都在bean类之中。Amber也提供了一种强制检测机制来验证内容，不过为了节约篇幅，就不在这篇文章中讨论了。
Amber只做了一件事并且做得很好：把数据库的列以及查询参数映射到JavaBean的属性。不多，也不少。Amber不是银弹，也没有解决那些庞大的工业O/R框架才能处理的问题。
Amber已经在一个商业环境中证明了它的价值。在Impetus，我们为一家德国最大的邮购公司提供了销售人员解决方案，系统基于Java，使用了MS SQL Server，而我们使用Amber处理了全部的数据库交互。自从今年春天(自从J2SE 5.0的到来)以来，我们没有改变一点API，而且使用中也没出现什么大问题。
资源
Matrix:http://www.matrix.org.cn
Onjava:http://www.onjava.com
Norbert Ehreke是一个顾问以及高级软件开发者，在德国法兰克福的Impetus Unternehmensberatung GmbH旗下工作。
↑返回目录
前一篇: 分页问题解决之道---共同学习共同进步
后一篇: 基于J2EE的三层B/S信息系统研究