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是有效的，但它确实提供了一些好处，因为它使您的应用程序逻辑持久性不可知。例如，通过不使用注释，您必须在整个应用程序中使用DynamoDB对象作为Map<String, Object>。通过使用映射器，您可以将DynamoDB中存储的项目作为User对象使用，并且您的业务逻辑都可以在User个对象上执行。

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

因此，虽然您必须使用DynamoDB注释来使用映射器，但是通过直接在域实体上实现应用程序逻辑而获得的好处远远超过了与连接到持久性解决方案的任何担忧，并且反映了它们的好处在我看来，JPA比你声称的更紧密。

Answer 2

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

由于POJO最有可能用于在a中跨层传输数据典型应用，例如从持久层到API层......这个把它与特定的数据库技术联系起来听起来不错。

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

我强烈建议你使用DynamoDBMapper

使用DynamoDBMapper是个坏主意吗？

2 个答案: