iOS上的核心数据替代品

我一直在使用核心数据开发多个iOS应用程序，它一直是一个很好的框架。但是，我遇到了一个问题，我们或多或少地在多个平台上分发了对象（同步）。 Web /数据库服务器后端和移动设备。尽管到目前为止它还没有成为问题，但Core Data所使用的数据模型的静态特性让我有点卡住了。基本上所要求的是一个动态表单系统，可以在服务器上创建表单并传播到设备。我知道的技术与表的一组数字的东西，如执行此：iOS上的核心数据替代品

形式表
字段表
形式表的实例
实例值表

并只将所有内容链接在一起。然而，我想知道的是，如果Core Data有一个替代系统（上面直接与SQLite数据库交谈），这将允许更加动态的对象图。如果有在运行时修改模式的选项，即使是标准的ORM也是很好的。我希望沿着这条路线走下去的主要原因是性能，因为我不希望实例值表中的条目爆炸（在本地设备或服务器上）。

我的其他选择是在iOS设备上有静态模式（对象图），但在服务器端有一个转换层，用于获取正确的对象，填充属性并将其保存到正确的表中。然后，当设备进行同步时，它会反转并将其分解成实例。虽然这样可以避免服务器拥有臃肿的实例值表，但它仍然可能是设备上的问题。

任何建议表示赞赏。

来源

2011-07-21 Dave Finster

嘿@Dave这个怎么样？ https://github.com/LakithaRav/OLCOrm – Laky

对表单和字段使用特定的表/实体，对每个实例使用实体，可能是我会推荐的。如果经常发生ORM架构试图操纵ORM架构通常看起来不是一个好主意。

但是，如果架构只会不经常更改，那么您可以使用Core Data来完成。您可以在创建NSManagedObjectContext之前以编程方式创建和/或操作NSManagedObjectModel。您还可以创建迁移逻辑，以便在更新模型时需要保存旧模型中存储的数据，并且需要重新创建上下文和存储。

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

来源

2011-07-21 13:45:23

啊，我正在寻找一些关于在运行时改变MOM的细节。感谢那些参考。实际上，我并不期望这个模型会频繁更改，但我只是在考虑应用程序的可扩展性（特别是在移动设备上）。我从doco猜测，一旦模型被改变（这归功于背景，可能在标准执行期间发生），那么我将不得不重新加载持久性存储（并迁移等）并重新初始化与数据库相关的所有内容。这是可行的，使用这种技术，我可能能够在平台之间共享数据模型。 –

你需要仔细想想你实际上建模。（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元素。

您可以使用核心数据来建模任何你只需要知道你真正建模的东西。

来源

2011-07-22 18:39:40 TechZen

我将要存储UI的信息，还要存储表单对象的实际数据布局。这里最主要的是表单本身是动态的（每个客户端，后端是多维的），因此对象图变化。我可以基于描述对象的固定表进行建模，也可以基于服务器在运行时动态构建对象模型。我想为每个模板使用单独的表格的原因是因为我们可能会得到大量数据。我知道你并不是想把核心数据看作是一个数据库，但是我们必须考虑性能。 –

这听起来像你可能实际上想要一个基于文档的设计，而不是标准的核心数据堆栈。在文档设计中，每个文档都有自己的堆栈，“文档”实际上只是一个持久存储区，只包含与一个逻辑文档相关的信息。就你而言，每个“文档”可能由两个商店组成：用于UI表单的商店和用于显示表单的数据的商店。如果一切都不同，每次都没有设计或API需要将所有这些差异塞进一个大商店。 – TechZen

我知道这是针对iOS的，但请查看MacOS NSPersistentDocument类来了解Core Data如何与文档体系结构配合使用。 – TechZen

iOS上的核心数据替代品

回答

相关问题