Realm Swift Models separate or not?

Question

I'm new to the world of iOS and Swift and am working on a new app which I want to use Realm for persistence. I have Entities in my code already which my Services access and populate for an HTTP API endpoint.

Now I want to persist certain Entities and wanted advice as to whether I should create new Realm specific Models for each of my entities to read and write from Realm. Or should I convert all my existing plain Swift Entities to Realm Entities. At first this felt wrong as I would be passing Realm Entities al around my app instead of just in the persistence layer.

However, the alternative is that every time I read/write entities to Realm I need to convert them back and forth from Entities to Realm Entities.

Any advice on the best approach to this?

Thanks

Answer 1

Both strategies are fine and have their own advantages and disadvantages.

Value Objects + Realm Objects

• ✅ Value objects are thread-safe
• ✅ Value objects can be mutated anywhere, without worrying about side-effects
• ✅ Value objects can be arbitrary defined and allow to use the full possibilities of the language, which allows to workaround constraints given by object persistence mapping
• ❗️ No lazily-loading, which means the full object hierarchy has to be loaded into memory
• ❗️ Can't express cycles
• ❗️ Requires to maintain your model definitions twice
• ❗️ Needs logic to map from transport encoding (e.g. JSON) to Swift Structs and from those to Realm Objects

Using only Realm Objects

• ✅ Zero-copy, which means reading from them is less expensive
• ✅ Live, which means their data is always up to date
• ✅ Lazily loaded from the database: fewer disk reads
• ✅ Can express cycles and arbitrary object hierarchies
• ✅ Define your model in one place
• ✅ If you can control the transport encoding and you can share naming conventions, you could rely mostly on Realm's integrated Foundation value type mapping logic used by create(_:update:_) and its friends.
• ✅ Supports KVO, which allow easy integration with some reactive programming frameworks
• ❗️ Adds constraints to the way how you define your model objects (Some language constructs are not directly supported as enums and require workarounds for now)
• ❗️ Reference types need more care for mutations to avoid undesirable side-effects, in addition modifications are only possible within write transactions (which should be batched to be as large as possible)
• ❗️ Realm Objects are not thread-safe

TL;DR

You lose many Realm features when opting out of Realm Objects and will have a hard-time to re-implement them yourselves. Depending on how much you need these and how your use-case looks like, you would buy thread-safety for a high cost.

In the long-term we're working on making Realm objects even easier to use and try to eliminate their disadvantages, so long being aware what those are will be helpful for making a well-informed decision.

Answer 2

From my point of view, all persistence interaction should be in classes called Store/Repository. If you want to change your database it will affect only Store/Repository classes. I think framework independency for application is more valuable than performance. You can use realm objects in case of performance problems, but i think the case of this situations is very rare.