Handling Entities and Pojos

Question

Still new to Room and while most of the tutorials I've found are related to simple table and CRUD operations I am stuck on evolving this.

Let's take this sample structures.

Users entity

@Entity(tableName = "users")

public class UsersEntity{
    @PrimaryKey(autoGenerate = true)
    private long id;

    @NonNull
    private String name;

    @NonNull
    private long roleId;
}

Roles entity

  @Entity(tableName = "roles")

    public class RolesEntity{
        @PrimaryKey(autoGenerate = true)
        private long id;

        @NonNull
        private String name;
    }

First question: Should Entity objects be extended to also replace POJO? Or have Entities and POJO as separate classes?

Extending from the Room setup, the way I would see User POJO is:

public class User{
   private long id;
   private Role role;
}

Basically this setup should work both if the User would come as a json response from a web service or entered by the user in the app's input fields.

However, this raises the second question: how to insert and retrieve user info?. Inserting seems possible as there could be something like

userDAO.insertRole(userId)

But how can I get the Role object of User by using Room and the userDAO? I find inappropriate to do something like:

user = userDao.getUser(userId)
user.setRole(roleDao.getRole(user.getRoleId)

Third question: it seems to be a good practice to have the table columns with _ (eg. role_id) but in java roleId is recommended as class property. If the result of a @Query for instance select role_id from... and the the POJO with roleId field, will fail so the query needs to be select role_id as roleId... to get it work. Is it a good practice to use camel case in table/column names in sqlite?

Answer 1

What you intend as POJO, probably can be seen as a kind of a view model. In general it is a bad idea to unify/link entities and pojos because you are just making a long wider visibilty/scope for the entity, where it is not necessary and can lead to potential problems.

Say you have some client which requires some different visualization of the data, for instance imagine you have a website which exposes a vehicle data and you have implemented everything using metric system, so for distance you have km, for speed km/h and so on. Now your company gains a huge client from UK, and they want you to provide them the data in imperial format. What to do now? Probably implement a deserilization/conversion process which takes the values and converts them according to the context of the user (whether they are using metric or imperial system). What could possibly go wrong if your entity and view model objects are basically the same? Really bad stuff. You have really tight coupling of things, you should implement different getters for serialization for client, for db..it can become a mess.

Instead if you separate the two, you will have your entity which takes care of working with the database, which is standard procedure with small coefficient of variability, and on the other side you will have the view model which is very likely to require frequent modification, after all it is expected, since it is the interface to the final user.