Database in a Multi-module Android Project
Nowadays, many Android developers adopt the concept of modularity in their projects. There are many reasons for why you should or shouldn’t modularize your project, but I won’t discuss it here.
Adding database has been one of my pet peeves when developing a multi-module Android project. In my opinion, there are no elegant ways to handle this issue.
But few days ago, I listened to the newest podcast episode by Fragmented Podcast which discussed about database in multi-module project. I really like one of the ways mentioned by Kaushik Gopal, and I want to share it in this post.
Generally, there are 2 approaches
- Create a database for each feature modules you have, in the module itself
- Create a single module that stores the database and all of the tables within
The first approach
The first way is to create a database in each feature module you have. By doing this, you isolate the database from one feature from the other features’.
It is good to have a clear boundary like this in a multi module project. But sometimes you want to have a relationship between tables in a database, and since this approach makes a separate database for each features, you cannot have relationship between the tables.
The second approach
This second way is the one mentioned by Kaushik Gopal. So, instead of having the database in each feature modules, we extract all of the tables from each modules in our projects and put it in a single database that resides in its own module. Each feature modules will then depend on this database module.
The pros of doing this is that you can have a relationship between tables in the database. But the cons of doing this is that all features can access all the tables, even the ones that do not necessarily needed. For instance, Feature A can access Table B.
In the podcast, Kaushik mentioned that we can create an intermediary module that creates an abstraction over the database module. This intermediary module will expose the database item for each domain.
So if Feature A does not need entries from Table B, it can just depends on Intermediary Module A. And if in the future it needs item from Table B, it can easily do so by depends on Intermediary Module B.
What if I need to query the data of multiple joint tables?
To do this, you can do it either by exposing a new intermediary module that expose relationship model between the tables or if you think it is still in the domain of one of the existing intermediary modules, you can just put it in the corresponding intermediary module.
You need to remember that by creating these intermediary modules, when your application grows and needs to store more types of data locally, you need to create intermediary modules for each one of them and it can be too much.
Which approach should I choose?
In the end, both approaches have its own pros and cons. It does not really matter much as long as your application works fine. Though I suggest that you use the second approach if you make an application with a complicated database which has some table relationships in it.
