我正在使用Siesta（并且很喜欢）Siesta与我的Swift App中的REST Web服务进行通信。我已经实现了一系列ResponseTransformers，以将API调用响应映射到模型类，以便Siesta资源自动解析为对象实例。这一切都很好。
我现在想实现一个Siesta PersistantCache对象，以通过使Siesta通过将这些对象存储在Realm中来将它们缓存到磁盘（而不是内存）中来支持脱机模式。我不确定如何执行此操作，因为该文档说（关于EntityCache.writeEntity函数）：
此方法可以并且应该检查实体的内容和/或标题，如果不可编码，则将其忽略。尽管它们可以应用基于类型的规则，但是缓存实现不应应用基于资源或基于url的规则。用于
Resource.configure(...)选择要缓存哪些资源以及由谁缓存。
为了符合该准则，我在服务配置期间基于URL模式匹配为每种资源类型创建了一个特定的PersistentCache对象：
class _GFSFAPI: Service {
private init() {
configure("/Challenge/*") { $0.config.persistentCache = SiestaRealmChallengeCache() }
}
但是，由于EntityCache协议方法仅包含对Entity的引用（公开原始内容，但不包含类型化的对象），因此我看不到如何在调用EntityCache.writeEntity的过程中调用领域写入方法或如何提取在EntityCache.readEntity期间将对象移出Realm。
任何有关如何解决此问题的建议将不胜感激。
很好的问题。EntityCache每个模型有一个单独的实现当然可以工作，尽管创建所有这些小的胶水类似乎很麻烦。
你writeEntity()叫什么用的出来结束所有响应变压器。如果您的变压器配置为吐出模型类，则writeEntity()可以看到模型。如果这些模型是Realm友好模型，那么我看不出您为什么不能只致电的任何原因realm.add(entity.content)。（如果这给您带来了问题，请及时告知我们。）
相反，当从缓存中读取内容时，readEntity()返回的内容不会再次通过转换器管道，因此它应该返回与您的转换器所产生的完全相同的东西，即模型。
您从文档中引用的特定段落写得不正确，并且可能会引起误解。当它说“您不应该应用基于资源或基于URL的规则”时，它实际上只是在劝说您不要解析forKey:参数-秘密地只是一个URL，但对于缓存实现应该保持不透明。但是，您可以从给定实体收集的任何信息都是公平的，包括的类型entity.content。
当前API下的一个难题-这是一个严重的难题-您需要保留从Siesta的键（应该将其视为不透明的）到不同类型的Realm对象的映射。您可以通过以下方式执行此操作：
siestaKey属性并在模型之间进行某种联合查询，或者我可能会按此顺序进行选择，但是我相信您在这里以Realm为后盾处于相对未开发（尽管完全合理）的领域EntityCache。一旦您解决了所有选项，我建议您为任何建议的API改进提出Github问题。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句