Architecture Design for Local Database ~ Realm, CoreData, SwiftData ~ Musa Yazici

Have you ever struggled with a local database?

Database objects come with so many rules!

For Example: Realm This Realm object cannot be retrieved or modified like a normal variable.

● Realm instance handling ● Use identical thread ● etc. Rules for Realm

There are so many rules for local database objects! For Realm 1. Crashes when accessing an object across threads 2. Crashes when editing a realm object outside of a realm.write {} block 3. Crashes when trying to access a property that is not in the model definition 4. 4. Crashes when trying to access a deleted realm object 5. 5. Crashes due to resource leakage or invalid state reference if Realm instance is not properly closed For CoreData 1. Crashes when Context is shared between different Threads 2. Crashes when trying to access a result set before a fetch request completes 3. Crashes when trying to access an entity that is not in the model definition 4. Crashes when manipulating a Managed Object that has been deleted or does not belong to a context. 5. Crashes when attempting to set data of an unexpected type for a model attribute 6. Crashes when compiled model does not match model in code

There are so many rules for local database objects! For Realm 1. Crashes when accessing an object across threads 2. Crashes when editing a realm object outside of a realm.write {} block 3. Crashes when trying to access a property that is not in the model definition 4. 4. Crashes when trying to access a deleted realm object 5. 5. Crash due to resource leakage or invalid state reference if Realm instance is not properly closed For CoreData 1. Crashes when Context is shared between different Threads 2. Crashes when trying to access a result set before a fetch request completes 3. Crashes when trying to access an entity that is not in the model definition 4. Crashes when manipulating a Managed Object that has been deleted or does not belong to a context. 5. Crash when attempting to set data of an unexpected type for a model attribute 6. Crashes when compiled model does not match model in code It’s hard to always take care of rules

Even if rules are violated, there are no compile errors and it’s difficult to find the violation in the code. It may not be found until someone crashes.

Database object rules are dangerous for both Quality and Efficiency

We want to use database objects without rules!

We can use Dummy Objects!

1.Prepare a database object and a normal object Dummy Object Realm Object

2. Allow objects to be converted from one to another Dummy Object Realm Object

3. Make service class for database operations Use non-Realm data in entire project

4. Fetch database objects after launch and convert them to normal object Fetch RealmCards and convert to Card Array

When the cards array is changed, synchronizeWithRealm() is called Convert Card to RealmCard and apply the data changes in background thread 5. Update database objects automatically whenever normal objects are updated

Normal Project Realm Card

All files that use RealmCard (View, ViewModel, Test, etc） Need to obey Realm rules Realm Card Normal Project

Using dummy object Fetch RealmCard after launch. Convert to Card Change Realm data whenever Card is changed Realm Card Card Realm Service

Using dummy object Fetch RealmCard after launch. Convert to Card Change Realm data whenever Card is changed Realm Card Card Realm Service Entire app uses non-Realm Card class. All the files except for RealmService are independent on Realm. Development can be done without thinking about Realm！

Benefits of using dummy objects 1. Improvement in maintainability and development efficiency Become independent of Database! Develop without thinking about it! 2. Great UI performance Data operations are executed in background thread. Local database can be slow with large amount of data, but it’s always fast with this architecture. 3. Easy to write tests Test execution is independent of database. Parallel execution can be enabled without effort. 4. Independence of the code You can migrate database by rewriting just a small part of your project.

Database objects are dangerous it's better to avoid touching them directly

Thank you!