Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Architecture Design for Local Database ~ Realm,...

ムッチョ
July 08, 2024
67

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

ムッチョ

July 08, 2024
Tweet

Transcript

  1. 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
  2. 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
  3. 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.
  4. 4. Fetch database objects after launch and convert them to

    normal object Fetch RealmCards and convert to Card Array
  5. 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
  6. All files that use RealmCard (View, ViewModel, Test, etc) Need

    to obey Realm rules Realm Card Normal Project
  7. Using dummy object Fetch RealmCard after launch. Convert to Card

    Change Realm data whenever Card is changed Realm Card Card Realm Service
  8. 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!
  9. 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.