Entity, DAO, Database classes in Android Kotlin - Deep Dive

Overview - Entity, DAO, Database classes

What is it?

In Android app development, Entity, DAO, and Database classes are key parts of Room, a library that helps apps store and manage data locally. An Entity represents a table in the database, DAO (Data Access Object) defines how to access and manipulate that data, and the Database class ties everything together to create the actual database. These classes work together to make saving, reading, and updating data easy and safe.

Why it matters

Without these classes, managing data in an app would be complicated and error-prone, requiring manual SQL queries and risking data loss or crashes. They provide a clear, structured way to handle data, making apps faster, more reliable, and easier to maintain. This means users get a smoother experience and developers spend less time fixing bugs.

Where it fits

Before learning these, you should understand basic Kotlin programming and how Android apps work. After mastering these classes, you can learn advanced database topics like migrations, relations, and integrating with live data or coroutines for reactive apps.

Mental Model

Core Idea

Entity, DAO, and Database classes form a simple, organized system that turns app data into tables, defines how to work with that data, and creates the database to store it all safely.

Think of it like...

Think of a library: the Entity is like a bookshelf (a place to hold books), the DAO is the librarian who knows how to find, add, or remove books, and the Database class is the whole library building that holds all the bookshelves and librarians together.

┌─────────────┐      ┌─────────────┐      ┌───────────────┐
│   Entity    │─────▶│     DAO     │─────▶│   Database    │
│ (Table)     │      │(Data Access)│      │ (Room DB)     │
└─────────────┘      └─────────────┘      └───────────────┘

Build-Up - 7 Steps

1

Foundation

What is an Entity class?

Concept: An Entity class defines a table in the database with columns as properties.

In Kotlin, you create an Entity by annotating a data class with @Entity. Each property becomes a column. For example: @Entity(tableName = "users") data class User( @PrimaryKey val id: Int, val name: String, val age: Int ) This creates a 'users' table with columns 'id', 'name', and 'age'.

Result

You get a clear blueprint for a database table that Room can use to create and manage data storage.

Understanding that an Entity is just a Kotlin class representing a table helps you see how code and database structure connect.

2

Foundation

Understanding DAO interfaces

Concept: DAO defines methods to insert, update, delete, and query data from the database.

A DAO is an interface annotated with @Dao. It contains functions with SQL queries or annotations like @Insert, @Delete, and @Query. Example: @Dao interface UserDao { @Insert suspend fun insertUser(user: User) @Query("SELECT * FROM users WHERE id = :userId") suspend fun getUserById(userId: Int): User? } This tells Room how to add and get users.

Result

You can call these functions in your app to safely access the database without writing raw SQL every time.

Knowing DAO separates data operations from UI logic keeps your app organized and easier to maintain.

3

Intermediate

Creating the Database class

Concept: The Database class connects Entities and DAOs and creates the Room database instance.

You create an abstract class annotated with @Database listing Entities and DAOs. Example: @Database(entities = [User::class], version = 1) abstract class AppDatabase : RoomDatabase() { abstract fun userDao(): UserDao } You then build the database with Room.databaseBuilder in your app.

Result

This class acts as the main access point to your database, letting you get DAO instances to work with data.

Seeing the Database class as the central hub clarifies how Room organizes data access in one place.

4

Intermediate

How Room generates code

🤔Before reading on: do you think Room runs your SQL queries at runtime or generates code ahead of time? Commit to your answer.

Concept: Room uses annotation processing to generate code that implements your DAO methods safely and efficiently.

When you build your app, Room reads your Entity and DAO annotations and creates classes that handle SQL queries and data mapping. This means you write simple Kotlin code, and Room does the heavy lifting behind the scenes.

Result

Your app runs faster and with fewer errors because Room handles SQL safely and optimizes queries.

Understanding Room's code generation explains why you don't see SQL code in your app but still get database functionality.

5

Intermediate

Using suspend functions in DAO

🤔Before reading on: do you think DAO methods should run on the main thread or background thread? Commit to your answer.

Concept: DAO methods often use suspend functions to run database operations off the main thread, keeping the app responsive.

By marking DAO functions with suspend, you tell Kotlin to run them asynchronously. For example: @Insert suspend fun insertUser(user: User) This prevents freezing the UI during slow database operations.

Result

Your app stays smooth and responsive even when reading or writing lots of data.

Knowing how suspend functions keep the UI responsive helps you write better user experiences.

6

Advanced

Handling database migrations

🤔Before reading on: do you think changing an Entity's structure requires special handling in Room? Commit to your answer.

Concept: When you change Entities, you must handle migrations to update the database without losing data.

Room requires you to define migration strategies when you increase the database version. For example: val MIGRATION_1_2 = object : Migration(1, 2) { override fun migrate(database: SupportSQLiteDatabase) { database.execSQL("ALTER TABLE users ADD COLUMN email TEXT") } } You add this migration when building the database to keep data safe.

Result

Your app updates smoothly without crashing or losing user data when the database changes.

Understanding migrations prevents data loss and app crashes during updates.

7

Expert

Optimizing with relations and embedded classes

🤔Before reading on: do you think Room supports complex data structures like nested objects directly? Commit to your answer.

Concept: Room supports relations between Entities and embedding objects to model complex data efficiently.

You can use @Relation to link tables and @Embedded to include objects inside Entities. For example: @Entity class UserWithAddress( @Embedded val user: User, @Relation( parentColumn = "id", entityColumn = "userId" ) val addresses: List

) This lets you fetch related data in one query.

Result

Your app handles complex data models cleanly and efficiently, reducing code and queries.

Knowing how to model relations unlocks powerful database designs for real apps.

Under the Hood

Room uses annotation processing at compile time to generate classes that implement your DAO interfaces. It maps Kotlin data classes (Entities) to SQLite tables and translates DAO methods into SQL queries. When your app runs, these generated classes execute SQL commands safely on the database, handling threading and data conversion automatically.

Why designed this way?

Room was designed to simplify SQLite usage in Android by removing boilerplate and reducing runtime errors. Using compile-time code generation ensures SQL correctness before the app runs, improving reliability and performance. Alternatives like raw SQL or ORM libraries lacked this safety or were too heavy, so Room balances simplicity, safety, and efficiency.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│  Kotlin Code  │──────▶│ Annotation    │──────▶│ Generated     │
│ (Entity, DAO) │       │ Processing    │       │ Classes       │
└───────────────┘       └───────────────┘       └───────────────┘
         │                      │                       │
         ▼                      ▼                       ▼
  ┌───────────────┐       ┌───────────────┐       ┌───────────────┐
  │ SQLite Tables │◀─────▶│ SQL Queries   │◀─────▶│ Runtime Calls │
  └───────────────┘       └───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think you can use any Kotlin class as an Entity without annotations? Commit to yes or no.

Common Belief: Any Kotlin data class can be used as an Entity without special annotations.

Reality: Only classes annotated with @Entity are recognized by Room as database tables.

Why it matters: Without @Entity, Room ignores the class, causing runtime errors or missing tables.

Quick: Do you think DAO methods run on the main thread by default? Commit to yes or no.

Common Belief: DAO methods automatically run on background threads, so you don't need to worry about threading.

Reality: DAO methods run on the calling thread unless marked suspend or called inside a coroutine or background thread.

Why it matters: Running database operations on the main thread can freeze the UI and cause app crashes.

Quick: Do you think Room automatically handles database schema changes without migrations? Commit to yes or no.

Common Belief: Room updates the database schema automatically when Entities change, no extra work needed.

Reality: You must provide migration strategies when changing the database version to avoid crashes or data loss.

Why it matters: Ignoring migrations leads to app crashes or corrupted data when updating the app.

Quick: Do you think the Database class can be instantiated directly with a constructor? Commit to yes or no.

Common Belief: You can create the Database class by calling its constructor like a normal class.

Reality: Room requires using Room.databaseBuilder or Room.inMemoryDatabaseBuilder to create the database instance.

Why it matters: Trying to instantiate directly causes errors because Room generates the implementation at compile time.

Expert Zone

1

Room's generated code caches prepared SQL statements for better performance, reducing query parsing overhead.

2

Using @Transaction on DAO methods ensures multiple database operations run atomically, preventing partial updates.

3

Room supports LiveData and Flow return types in DAO for reactive UI updates, integrating with Kotlin coroutines.

When NOT to use

Room is not ideal for very large or complex databases requiring advanced SQL features or multi-process access. Alternatives like SQLiteOpenHelper or external databases (Realm, ObjectBox) may be better for those cases.

Production Patterns

In production, developers use Repository patterns to abstract DAOs, combine Room with ViewModel and LiveData for UI updates, and implement migrations carefully to handle app updates without data loss.

Connections

Object-Relational Mapping (ORM)

Room is a lightweight ORM for Android, mapping objects to database tables.

Understanding Room helps grasp how ORMs simplify database work by connecting code objects to data storage.

Reactive Programming

Room integrates with LiveData and Kotlin Flow to provide reactive data streams.

Knowing Room's reactive features helps build apps that update UI automatically when data changes.

Library Management Systems

The Entity-DAO-Database pattern mirrors how libraries organize books, librarians, and buildings.

Seeing this connection clarifies how software structures data access similarly to real-world systems.

Common Pitfalls

#1 Running database queries on the main thread causing UI freezes.

Wrong approach:

@Query("SELECT * FROM users")
fun getAllUsers(): List // Called on main thread

Correct approach:

@Query("SELECT * FROM users")
suspend fun getAllUsers(): List // Called inside coroutine

Root cause:

Not marking DAO methods as suspend or not using background threads leads to blocking the UI.

#2 Forgetting to add @PrimaryKey in Entity causing runtime errors.

Wrong approach:

@Entity
data class User(
val id: Int,
val name: String
)

Correct approach:

@Entity
data class User(
@PrimaryKey val id: Int,
val name: String
)

Root cause:

Room requires a primary key to identify rows; missing it breaks database creation.

#3 Changing Entity structure without providing migration causing app crashes.

Wrong approach:

Increasing database version without migration:
@Database(entities = [User::class], version = 2)
abstract class AppDatabase : RoomDatabase() { ... }

Correct approach:

Providing migration object:
val MIGRATION_1_2 = object : Migration(1, 2) { ... }
Room.databaseBuilder(context, AppDatabase::class.java, "db")
.addMigrations(MIGRATION_1_2)
.build()

Root cause:

Room cannot update schema automatically; missing migration causes crashes.

Key Takeaways

Entity classes define the structure of your database tables using simple Kotlin data classes.

DAO interfaces provide clear, safe methods to access and modify your database without writing raw SQL.

The Database class connects Entities and DAOs, creating the Room database instance your app uses.

Room generates code at compile time to handle SQL queries efficiently and safely, reducing runtime errors.

Proper use of suspend functions and migrations ensures your app stays responsive and data remains safe during updates.