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

Transcript

1. Architecture Design for Local Database ~ Realm, CoreData, SwiftData ~ Musa Yazici
2. Have you ever struggled with a local database?
3. Database objects come with so many rules!
4. For Example: Realm This Realm object cannot be retrieved or modified like a normal variable.
5. • Realm instance handling • Use identical thread • etc. Rules for Realm
6. 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
7. 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
8. 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.
9. Database object rules are dangerous for both Quality and Efficiency
10. We want to use database objects without rules!
11. We can use Dummy Objects!
12. 1.Prepare a database object and a normal object Dummy Object Realm Object
13. 2. Allow objects to be converted from one to another Dummy Object Realm Object
14. 3. Make service class for database operations Use non-Realm data in entire project
15. 4. Fetch database objects after launch and convert them to normal object Fetch RealmCards and convert to Card Array
16. 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
17. Normal Project Realm Card
18. All files that use RealmCard (View, ViewModel, Test, etc） Need to obey Realm rules Realm Card Normal Project
19. Using dummy object Fetch RealmCard after launch. Convert to Card Change Realm data whenever Card is changed Realm Card Card Realm Service
20. 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！
21. 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.
22. Database objects are dangerous it's better to avoid touching them directly
23. Thank you!