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

现在假设您需要切换以将您的用户存储在不同的数据库中......无论出于何种原因，MongoDB 或什至是关系数据库。是的，您必须更改 User 上的注释反对什么与你的新持久性存储需要的东西一起工作(就像你必须修改其中的一些，如果你使用 JPA 但从 MySQL 切换到 Postgres)，但是你的应用程序逻辑，即业务User 上的规则和验证整个应用程序中的对象不必更改。

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