Модели Realm Swift разделены или нет?

Я новичок в мире iOS и Swift, и я работаю над новым приложением, которое я хочу использовать Realm для настойчивости. У меня уже есть объекты в моем коде, которые мои службы получают и заполняют для конечной точки HTTP API.

Теперь я хочу удержать определенные сущности и хотел получить совет относительно того, следует ли создавать новые Realm-специфические модели для каждого из моих сущностей для чтения и записи из Realm. Или мне нужно преобразовать все существующие обычные Swift Entities в Realm Entities. Поначалу это было не так, как если бы я передавал Realm Entities al вокруг моего приложения, а не только на уровне сохранения.

Однако альтернативой является то, что каждый раз, когда я читаю/записываю сущности в Realm, мне нужно преобразовать их обратно и назад из Entities в Realm Entities.

Есть ли советы по наилучшему подходу к этому?

Спасибо

Ответ 1

Обе стратегии хороши и имеют свои преимущества и недостатки.

Объекты значения + объекты в области объектов

✅ Объекты Value являются потокобезопасными
✅ Объекты значения могут быть мутированы в любом месте, не беспокоясь о побочных эффектах.
✅ Объекты значения могут быть произвольно определены и позволяют использовать полные возможности языка, что позволяет обходным ограничениям, определяемым отображением сохранения объектов
❗️ Нет ленивой загрузки, что означает, что полная иерархия объектов должна быть загружена в память.
❗️ Невозможно выразить циклы
❗️ Требуется дважды поддерживать определения модели.
❗️ Требуется логика для отображения из транспортного кодирования (например, JSON) в Swift Structs и из объектов Realm Objects

Использование только объектов Realm

✅ Нулевая копия, что означает, что чтение из них менее дорого
✅ Live, что означает, что их данные всегда обновляются
✅ лениво загружается из базы данных: меньше дисков читается
✅ Может выражать циклы и произвольные иерархии объектов.
✅ Определите свою модель в одном месте.
✅ Если вы можете управлять транспортной кодировкой, и вы можете обмениваться соглашениями об именах, вы можете в основном полагаться на встроенную в Realm интегрированную логику отображения типа значения Foundation, используемую create(_:update:_) и ее друзьями.
✅ Поддерживает KVO, которые позволяют легко интегрироваться с некоторыми платформами реактивного программирования.
❗️ Добавляет ограничения на способ определения ваших объектов модели (некоторые языковые конструкции не поддерживаются непосредственно как перечисления и требуют обходных решений на данный момент)
❗️ Типы ссылок нуждаются в большем внимании к мутациям, чтобы избежать нежелательных побочных эффектов, кроме того, модификации возможны только в транзакциях записи (которые должны быть упакованы как можно больше).
❗️ Объекты Realm не являются потокобезопасными

TL; DR

Вы теряете многие функции Realm при отказе от объектов Realm и испытываете трудности с их повторной реализацией. В зависимости от того, насколько вам это необходимо и как выглядит ваш случай использования, вы бы приобрели безопасность потоков за высокую стоимость.

В долгосрочной перспективе мы работаем над тем, чтобы объекты Realm были еще проще в использовании и пытались устранить их недостатки, так как давно известно, что они будут полезны для принятия обоснованного решения.

Ответ 2

С моей точки зрения, все взаимодействия настойчивости должны быть в классах, называемых Store/Repository. Если вы хотите изменить свою базу данных, это повлияет только на классы Store/Repository. Я считаю, что независимость от каркаса для приложений более ценна, чем производительность. Вы можете использовать объекты сферы в случае проблем с производительностью, но я думаю, что случай с такими ситуациями встречается очень редко.