使用 DynamoDBMapper 是个坏主意吗？

Question

我开始使用 DynamoDB，并在 DynamoDBMapper 上看到了这条指令 http://aws.amazon.com/articles/0802321832592496

假设我有一个用户 POJO，DynamoDB 注释添加如下：

@DynamoDBTable(tableName = "users")
public class User {

    private Integer id;
    private Set<String> friends;
    private String status;

    @DynamoDBHashKey
    public Integer getId() { return id; }
    public void setId(Integer id) { this.id = id; }

    @DynamoDBAttribute
    public Set<String> getFriends() { return friends; }
    public void setFriends(Set<String> friends) { this.friends = friends; }

    @DynamoDBAttribute
    public String getStatus() { return status; }
    public void setStatus(String status) { this.status = status; }
}

由于 POJO 最有可能用于在典型应用程序中跨层传输数据，例如从持久层到 API 层......这听起来像是一个坏主意，将其与特定的数据库技术联系起来。

在关系领域，可以使用与数据库无关的 Java Persistence API 注释。但对于 DynamoDB，情况并非如此。如果将来更改数据库，我们将需要修改 POJO 类。听起来不是一个好习惯。

那么应该使用 DynamoDBMapper，还是应该只使用较低级别的 API？

Answer 1

JPA 的目标是与数据库无关，但任何将实际应用程序从一个数据库迁移到另一个数据库的人都可以告诉您，它不能处理所有的边缘情况。

虽然您关于 DynamoDB 注释特定于 DynamoDB 的观点是有效的，但它确实提供了一些好处，因为它使您的 应用程序 逻辑持久性不可知。例如，如果不使用注释，您将不得不在整个应用程序中以 Map<String, Object> 的形式使用 DynamoDB 对象。通过使用映射器，您可以将存储在 DynamoDB 中的项目作为User 对象处理，并且您的业务逻辑都可以在User 对象上执行。

现在假设您需要切换以将用户存储在不同的数据库中……MongoDB 甚至是关系数据库，无论出于何种原因。是的，您必须将 User 对象上的 注释 更改为适用于您的新持久性存储所需的内容（就像您在使用 JPA 时必须修改其中一些一样但从 MySQL 切换到 Postgres），但您的 application 逻辑，即整个应用程序中 User 对象的业务规则和验证，不必更改。

因此，虽然您必须使用 DynamoDB 注释来使用映射器，但通过直接在域实体上实现应用程序逻辑所获得的好处远远超过了与持久性解决方案耦合的任何担忧，并反映了这些好处在我看来，JPA 比你断言的更接近。

Answer 2

提供映射器的唯一目的是自动创建 POJO，您应该使用它。

由于 POJO 最有可能用于在一个 典型应用，例如从持久层到 API 层……这个 将其与特定的数据库技术联系起来听起来是个坏主意。

这是技术的一个已知限制，甚至 hibernate（一个非常流行的 ORM 工具）也提供了一个类似的工具来从 db 创建 pojo，它也有同样的限制，如果你的 Db 不断变化，你可以创建新的pojo的

我强烈建议您使用 DynamoDBMapper