Java开发2.0: 使用Amazon SimpleDB实现云存储，第2部分

核心提示：Java开发2.0: 使用Amazon SimpleDB实现云存储，第2部分：使用SimpleJPA实现简单对象持久化使用诸如 Grails 的关系框架对几乎所有类型的应用进行域对象建模是很容易的，Java开发2.0: 使用Amazon SimpleDB实现云存储，第2部分，但是使用 SimpleDB 又怎么样呢？在

Java开发2.0: 使用Amazon SimpleDB实现云存储，第2部分：使用SimpleJPA实现简单对象持久化

使用诸如 Grails 的关系框架对几乎所有类型的应用进行域对象建模是很容易的，但是使用 SimpleDB 又怎么样呢？在 Andrew Glover 的介绍 SimpleDB 的系列文章的第 2 部分，他向您介绍了如何使用 SimpleJPA，而非 Amazon SDK，在 SimpleDB 的云存储中实现对象持久化。除了使您能够使用简单 Java™ 对象进行域建模（通过 JPA）之外，SimpleJPA 还能够自动地将基本数据类型转换成兼容 Amazon 的字符串。您确实找不到比这更简单的云存储方法了。

在介绍 SimpleDB 文章的 第一部分 中，我向您介绍了如何使用 Amazon 本身的 API 进行一个 CRUD 网络的赛跑应用的建模。除了对大多数 Java 开发人员而言，Amazon 只使用字符串来描述数据类型的方法的明显独特性之外，您可能发现自己对于 Amazon API 还有一些疑虑。毕竟，现在使用关系数据库的 API 已经非常标准且成熟了 — 而且更重要的是，他们已经很熟悉这些技术了。

除此之外，现在有许多关系框架实现了 Java Persistence API。因此为各种 RDBMS 进行各种类型的 Java 应用进行域对象建模都是非常容易和常见的。当您已经掌握了一种方法之后，很自然您会对于学习新的域对象建模方法会有一些抵触 — 而好消息是使用 SimpleDB 时，您不需要学习新东西。

在 SimpleDB 文章的第 2 部分中，我将向您介绍如何重构第 1 部分的赛跑应用，使之符合 JPA 规范。然后我们将把应用移植到 SimpleJPA，并且探讨一些能够使这个创新的开放源码平台经过调整而支持 NoSQL 域建模和基于云的存储的方法，这一样很简单。

为什么使用 SimpleDB？

Amazon 的 SimpleDB 是一个简单且极具可扩展性和可靠性的基于云的数据存储方法。由于它本质上是非关系/NoSQL，SimpleDB 既灵活又快速。作为 Amazon Web Service 家族的一部分，SimpleDB 使用 HTTP 作为底层通信机制，所以它能够支持多种语言，包括 Java 语言、Ruby、C# 和 Perl。SimpleDB 价格也很便宜：根据 SimpleDB 的授权方式，您只需要为您使用的资源支付费用，这跟根据预计使用和空间预先购买授权的传统方法很不一样。作为新兴的 NoSQL，或非关系数据存储的一部分，SimpleDB 是与 Google 的 Bigtable 或 CouchDB 相对应的，它们在 这些系列文章中 有相应的介绍。

Hibernate 和 JPA：背景概况

现在有许许多多的 Java 开发人员都使用 Hibernate（和 Spring）实现数据持久化。除了是最先成功的开放源码项目，Hibernate 也彻底改变了 ORM 领域。在出现 Hibernate 之前，Java 开发人员必须处理复杂的 EJB 实体 Bean；而在这之前，我们只能自己实现 ORM 或者使用来自诸如 IBM® 等供应商的产品。Hibernate 去掉了 EJB 的所有复杂性和开销，转而使用我们现在许多人都使用的基于 POJO 的建模平台。

Java Persistence API (JPA) 是由于 Hibernate 创新地使用 POJO 进行数据建模方法的流行而出现的。现在，EJB 3.0 实现了 JPA，Google App Engine 也一样实现了 JPA。甚至如果您使用 Hibernate EntityManager，那么 Hibernate 本身也是一个 JPA 实现，

既然 Java 开发人员已经越来越熟悉使用 POJO 对以数据为中心的应用进行建模，那么可以说，SimpleDB 这样一个数据存储应该能够给我们提供一个类似的选项。毕竟，它与数据库有些相似，不是吗？

用对象进行数据建模

要使用 SimpleJPA，我们需要修改一下我们的 Racer 和 Runner 对象，使它们符合 JPA 规范。幸好，JPA 基本要素是很简单的：给平常的 POJO 加上注释，而 EntityManager 实现会负责完成其他处理 — 不需要 XML。

JPA 所使用的两个主要的注释是 @Entity 和 @Id，这两个注释分别将一个 POJO 指定为持久化类，同时确定它的标识键。为了将我们的赛跑应用转换为 JPA，我们也将使用另外两个管理关系的注释：@OneToMany 和 @ManyToOne。

在本文的第 1 部分中，我已经向您介绍了如何持久化选手和比赛对象了。然而，我没有使用对象来表示这些实体 — 我只是使用了 Amazon 的原始 API 来存储这两个对象的属性。如果我希望对一个比赛和比赛选手的关系进行建模，那么我可以编写如清单 1 所示的代码：

清单 1. 一个简单的 Race 对象

public　class　Race　{
　 private　String　name;
　 private　String　location;
　 private　double　distance;
　 private　List<Runner>　runners;

　 //setters　and　getters　left　out...
}

在 清单 1 中，我给 Race 对象设置了 4 个属性，最后一个是一个选手 Collection。接下来，我可以创建一个简单的 Runner 对象（如清单 2 所示），它包含每位选手的姓名（现在我将尽量保持简单），与他/她所参加的 Race 实例相关的 SSN。

清单 2. 与 Race 相关的一个简单的 Runner

public　class　Runner　{
　 private　String　name;
　 private　String　ssn;
　 private　Race　race;

　 //setters　and　getters　left　out...
}

您可以从 清单 1 和 2 看到，我在选手和比赛之间逻辑上建立了一个多对一的关系。在实际情况中，可能多对多关系更准确些（选手一般会参加多个比赛），但是这里这样做是为了简单起见。另外，现在我也忽略构造函数、setter 和 getter。我将在后面向您介绍。