Room Entities as DTOs

This works, and it is not that difficult to set up. However, the resulting classes are tightly coupled to the underlying SQLite table structure and give us a clunky object model. A traditional object-oriented design usually does not involve separate objects representing relations, the way BookCategoryJoin does, for example.

In addition, not only is our code a bit clunky today, but it might need to change in the future in ways that make it worse. That could be due to changes in Room or due to changes in the data model (e.g., adding a Library and BookLibraryJoin).

For simple apps, you might just live with the odd object model. For larger apps, it may make sense to treat Room entities as “data transfer objects” (DTOs) that you convert into a preferred object model. For example:

• We could have BookEntity, CategoryEntity, etc. that model our tables
• We could have Book and Category as our object model, where Book and Category actually refer to each other
• A repository could use Room as a local data source and map between the Room-structured entity classes and the “pure” object model represented by Book and Category

You might already be doing some of this sort of mapping in other areas. For example, larger apps often choose to use an object model that is separate from the objects used in Web service calls, as the way the Web service API is structured might be unnatural in the client app. Plus, the Web service API might be modified by the server team, and it may be useful to minimize the impact of those changes on the majority of your application code.