Siesta 的模型架构和持久性
Model architecture and persistance for Siesta
我是 Swift 的新手，来自 Restkit，我找到了 Siesta，它似乎是一个解决常见问题的可靠库。
目前我正在尝试弄清楚如何处理我的应用程序的模型层及其持久性。 CoreData 是 Apple 推动的一种方法，而像 MagicalRecord 这样的东西让它变得更容易。
但是，Siesta 不处理 CoreData，我不清楚缓存是如何工作的（或者它实现了多远：
Siesta currently does not include any implementations of EntityCache, but a future version will.
http://bustoutsolutions.github.io/siesta/api/Caching.html
从示例中，我可以看到您只在 Swift 代码中定义了模型：
https://github.com/bustoutsolutions/siesta/blob/master/Examples/GithubBrowser/Source/Model/User.swift
那么：这是模型层的最佳方法还是 CoreData/MagicalRecord 有作用？在这种情况下缓存是如何完成的，它会在应用程序启动之间存活吗？
谢谢！
第一个问题是：本地数据库（比如 Core Data 或 Realm）能为你解决什么问题？根据答案，您可能不需要 - 或者 Siesta 可能不适合您。
“我只需要缓存”
Siesta 免费进行内存缓存。如果您只需要在应用程序 运行 时缓存以加快速度（即防止冗余请求、跨 VC 显示数据等），那么您可能不需要为 EntityCache 或本地数据库操心.
大多数应用都属于这一类。
“我需要离线访问”
如果您需要持久缓存以进行离线访问或使用陈旧数据进行快速启动，这就是 EntityCache 的用途。您仍然可能不需要本地数据库；一个简单的键值缓存就可以了。不幸的是：
- A public 在 Siesta 1.0 完成之前，EntityCache 实现超出范围。
Siesta 的当前缓存 API 目前不太适合使用模型。 更新： 缓存 API 现在可以很好地缓存模型，解析 JSON 或其他 ADT，或原始字节。
“我需要一个可查询的数据库”
也许您的需求不仅仅是缓存。也许您想从许多不同的 API 请求中获取数据并进行查询，例如“select 所有以前获取的供应商位置在莫桑比克的小部件。”这显然是数据库的工作。
此时，您不仅仅是在缓存；您保持本地状态与远程状态同步，并独立查询远程和本地副本。这是一个非常依赖环境的解决方案的混乱问题，远远超出了 Siesta 的范围。
您可以让 Siesta 使用本地数据库，但它会变得混乱。如果你能避免改变本地数据库，让它成为来自服务器的权威数据的单向镜像，你的生活将会变得最轻松。
我是 Swift 的新手，来自 Restkit，我找到了 Siesta，它似乎是一个解决常见问题的可靠库。 目前我正在尝试弄清楚如何处理我的应用程序的模型层及其持久性。 CoreData 是 Apple 推动的一种方法，而像 MagicalRecord 这样的东西让它变得更容易。
但是，Siesta 不处理 CoreData，我不清楚缓存是如何工作的（或者它实现了多远：
Siesta currently does not include any implementations of EntityCache, but a future version will.
http://bustoutsolutions.github.io/siesta/api/Caching.html
从示例中，我可以看到您只在 Swift 代码中定义了模型： https://github.com/bustoutsolutions/siesta/blob/master/Examples/GithubBrowser/Source/Model/User.swift
那么：这是模型层的最佳方法还是 CoreData/MagicalRecord 有作用？在这种情况下缓存是如何完成的，它会在应用程序启动之间存活吗？
谢谢！
第一个问题是：本地数据库（比如 Core Data 或 Realm）能为你解决什么问题？根据答案，您可能不需要 - 或者 Siesta 可能不适合您。
“我只需要缓存”
Siesta 免费进行内存缓存。如果您只需要在应用程序 运行 时缓存以加快速度（即防止冗余请求、跨 VC 显示数据等），那么您可能不需要为 EntityCache 或本地数据库操心.
大多数应用都属于这一类。
“我需要离线访问”
如果您需要持久缓存以进行离线访问或使用陈旧数据进行快速启动，这就是 EntityCache 的用途。您仍然可能不需要本地数据库；一个简单的键值缓存就可以了。不幸的是：
- A public 在 Siesta 1.0 完成之前，EntityCache 实现超出范围。
Siesta 的当前缓存 API 目前不太适合使用模型。更新： 缓存 API 现在可以很好地缓存模型，解析 JSON 或其他 ADT，或原始字节。
“我需要一个可查询的数据库”
也许您的需求不仅仅是缓存。也许您想从许多不同的 API 请求中获取数据并进行查询，例如“select 所有以前获取的供应商位置在莫桑比克的小部件。”这显然是数据库的工作。
此时，您不仅仅是在缓存；您保持本地状态与远程状态同步，并独立查询远程和本地副本。这是一个非常依赖环境的解决方案的混乱问题，远远超出了 Siesta 的范围。
您可以让 Siesta 使用本地数据库，但它会变得混乱。如果你能避免改变本地数据库，让它成为来自服务器的权威数据的单向镜像，你的生活将会变得最轻松。