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上的核心數據替代品

回答

相關問題