CODEWITHSUNDEEP
javaamazon-dynamodb
vuamitom
vuamitom

Reputation: 198

Is using DynamoDBMapper a bad idea?

I've started on DynamoDB and came across this instruction on DynamoDBMapper http://aws.amazon.com/articles/0802321832592496

Let say I have a User POJO, DynamoDB annotations are added like: 

@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; }
}

Since the POJO is most likely used to carry data across layers in a typical application, e.g from persistence layer to API layer ... This sound like a bad idea to tie it to a specific database technology.

In the relational realm, one would use the Java Persistence API annotation, which is database agnostic. But for DynamoDB, it's not the case. And in case database is changed in the future, we will need to modify the POJO class. Does not sound like a good practice.

So should the DynamoDBMapper be used, or should I just use lower level API?

Upvotes: 1

Views: 2934

Answers (2)

rpmartz
rpmartz

Reputation: 3809

JPA aims to be database agnostic, but anyone who has actually migrated a real application from one database to another can tell you that it doesn't handle all of the edge cases.

While your point that the DynamoDB annotations are specific to DynamoDB is valid, it does afford some benefits in that it keeps your application logic persistence agnostic. For example, by not using the annotations you would have to work with DynamoDB objects as Map<String, Object> all throughout your application. By using the mapper, you can instead work with the items stored in DynamoDB as User objects and your business logic can all be performed on User objects.

Now let's say you need to switch to store your users in a different database...MongoDB or even a relational DB for whatever reason. Yes, you'd have to change the annotations on the User object to what works with what your new persistence store requires (just like you'd have to modify some of them if you were using JPA but switched from MySQL to Postgres), but your application logic, i.e business rules and validation on the User objects throughout the application, does not have to change.

So, while you do have to use DynamoDB annotations to use the mapper, the benefits you gain by being able to implement your application logic directly on your domain entities far outweigh any concerns over coupling to a persistence solution, and mirror the benefits of JPA more closely than you assert, in my opinion.

Upvotes: 3

Aniruddha K.M
Aniruddha K.M

Reputation: 7511

The mapper is provided for the sole purpose of creating the POJO's automatically and you should make use of it.

Since the POJO is most likely used to carry data across layers in a typical application, e.g from persistence layer to API layer ... This sound like a bad idea to tie it to a specific database technology.

This is a known limitation of the technology,Even hibernate(a very popular ORM tool) had provided a similar tool to create pojo from db and it also had the same limitation, If your Db keeps changing with time you can create new pojo's

I would strongly suggest you use the DynamoDBMapper

Upvotes: 0

Related Questions