Menu
If I have a Database(DB) containing two tables/entities (A and B), should I make a DAO for each entity? (Ie DAO_A and DAO_B), Or do I make a DAO for the whole DB containing these two tables?
Then as regards the repository, will this be a repository for the whole Database(whole of DB) or just a repository for the database with only the relevant DAO's I want the class for (ie DAO_A and DAO_B). (Realy what I think I am asking here is will the Database have multiple repositories or just one repository, and will each entity have to have its own DAO, or can I make a general D
975
There is no such rule that you have to make separate @Dao for every table. You can make one Dao class that holds all of your database queries. But just with the convention, you make separate Dao for every entity.
When you use the Room persistence library to store your app's data, you interact with the stored data by defining data access objects, or DAOs. Each DAO includes methods that offer abstract access to your app's database. At compile time, Room automatically generates implementations of the DAOs that you define.
Room is a persistence library that's part of Android Jetpack. Room is an abstraction layer on top of a SQLite database. SQLite uses a specialized language (SQL) to perform database operations.
The Room persistence library provides an abstraction layer over SQLite to allow for more robust database access while harnessing the full power of SQLite. Latest Update.
The tutorial will make use of all of the elements covered in The Android Room Persistence Library including entities, a Data Access Object, a Room Databases and asynchronous database queries.
Today we’re gonna look out a new Android Architecture Component library called Room . The room is basically a “Persistence library that provides an abstraction over SQLite “. The room is a new way to create the database in your Android apps.
At compile time, Room will generate an implementation of this class when it is referenced by a Database . An abstract @Dao class can optionally have a constructor that takes a Database as its only parameter. It is recommended to have multiple Dao classes in your codebase depending on the tables they touch.
Android Room Persistence Library: Relations in a Nested One-To-Many Relationship. Relation is a convenience annotation which can be used in a Pojo to automatically fetch relation entities. When the Pojo is returned from a query, all of its relations are also fetched by Room.
I would say go for every entity has its own DAO. Why? Because you properly separate them.
Let's say you would have a DAO which contains Entity A and B. In your repository you might only need Entity A, then it would not make any sense that this DAO uses Entity B as well. If a case occurs, where you need both Entities, just use both DAO's. A further reason for seperate DAO's is that you don't know how to couple Entities properly. How are you going to decide which Entities to couple into a DAO? Yes you could decide this depending on the Repository which makes use of it, but this can lead to code duplication (two DAO's make use of the same Entity, but each of those also use a second one - which is different for each DAO).
Regarding your second question: I believe it depends on your architecture how exactly your repository should be modeled.
For example when using MVVM:
Requirement: You have an Activity just displaying a list of images fetched from somewhere.
Then your ViewModel would offer a function like getAllImageModels or something similar. Each of those ImageModels would include an image (which will be displayed). Inside this function the Repository is called either an API call to retrieve a list of images to download or a database call to retrieve the list from the database (depending on internet connection). These images must be downloaded as well. Again images could be loaded from your local cache or downloaded via the API. Then the ViewModel wraps them in the desired model required by the View and thats it.
As you can see by this simple example, the Repository on its own just performs requests. Either to the local filesystem, database or API. It could have functions like getImageListFromDb and getImageListFromAPI in it. So that the classes which make use of it just have to decide when to use what.
52
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
