iOS上的Core Data替代方案

4
我一直在使用Core Data开发多个iOS应用,这是一个非常出色的框架。但是,我遇到了一个问题,即我们需要在多个平台上分布对象(同步)。一个web/database服务器后端和移动设备。
虽然这不是问题,但Core Data所使用的数据模型的静态特性使我有点困惑。基本上,被请求的是一个动态表单系统,其中表单可以在服务器上创建并传播到设备。我知道可以使用一些带有固定数量表格的技术来执行此操作,例如:
- 表单表 - 字段表 - 表单实例 - 实例值表
只需将所有东西链接在一起。然而,我想知道是否有替代Core Data的系统(高于直接与SQLite数据库通信),它将允许更动态的对象图。即使有标准ORM,如果有运行时修改模式的选项也会很好。我之所以想走这条路,主要是为了性能,因为我不想在本地设备或服务器上让实例值表爆炸。
我的另一个选择是在iOS设备上使用静态模式(对象图),但在服务器端使用转换层,该层获取正确的对象,填充属性并将其保存到正确的表中。然后,当设备进行同步时,它会将其反转并将其拆分成实例。虽然这可以使服务器免受实例值表的膨胀,但在设备上仍可能存在问题。
欢迎任何建议。

嘿,@Dave,这个怎么样?https://github.com/LakithaRav/OLCOrm - Laky
2个回答

1

对于表单和字段,使用特定的表/实体以及每个实例的实体可能是我推荐的做法。如果需要频繁地在ORM模式上进行操作,则通常不建议动态更改它。

但是,如果模式很少更改,您可以使用Core Data来处理。在创建NSManagedObjectContext之前,可以使用编程方式创建和/或操作NSManagedObjectModel。您还可以创建迁移逻辑,以便在更新模型并需要重新创建上下文和存储时保留旧模型中存储的数据。

这些其他SO帖子可能有所帮助:


啊,我正在寻找有关在运行时更改 MOM 的详细信息。感谢提供这些参考资料。实际上,我并不希望模型经常更改 - 但是我只是考虑应用程序的可扩展性(特别是在移动设备上)。我猜测根据文档,一旦修改了模型(由于后台处理,可能会在标准执行期间发生),那么我将不得不重新加载持久存储(并进行迁移等操作)并重新初始化所有与数据库相关的内容。这是可行的,并且使用此技术,我可以在平台之间共享数据模型。 - Dave Finster

0
你需要仔细考虑你实际上要建模的内容。
你是在建模:(1)实际的“表单”,即UI元素,(2)可能呈现在任意数量的UI版本中的数据,例如firstName或(3)两者都有?
一个旨在建模表单的数据模型将具有如下实体:
Form{
  name:string
  fields<-->Field.form
}

Field{
  width:number
  height:number
  xPos:number
  yPos:number
  label:sting
  nextTab<-->Field.priorTab
  priorTab<-->Field.nextTab
  form<<-->Form.fields
}

您可以使用此功能来存储有关表单在用户界面中显示的数据。然后,您将拥有单独的实体和可能是单独的模型来存储实际数据,这些数据将填充由第一个数据模型配置的 UI 元素。

您可以使用 Core Data 对任何内容进行建模,只需要知道您真正要建模的内容。


我将存储UI信息和表单对象的实际数据布局。主要问题在于表单本身是动态的(每个客户端,后端是多租户),因此对象图会发生变化。我可以根据描述对象的固定表格进行建模,也可以基于服务器在运行时动态构建对象模型。我想为每个模板使用单独的表格,因为我们可能会有大量数据。我知道你不应该将Core Data视为数据库,但从性能角度考虑必须这么做。 - Dave Finster
听起来你可能实际上想要一个基于文档的设计而不是标准的 Core Data 栈。在文档设计中,每个文档都有自己的栈,而“文档”实际上只是一个持久性存储器,包含与一个逻辑文档相关联的信息。在你的情况下,每个“文档”可能由两个存储器组成:一个用于 UI 表单,另一个用于在表单中显示的数据。如果每次都是不同的,那么就没有必要将所有这些差异压入一个大存储器中的设计或 API 需求。 - TechZen
我知道这是针对iOS的,但是看一下MacOS的NSPersistentDocument类,以了解Core Data如何与文档架构配合工作。 - TechZen

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接