问题
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
回答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.
回答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.
来源：https://stackoverflow.com/questions/34943550/realm-swift-models-separate-or-not