核心資料變得更好

設定核心資料堆疊一直很麻煩。因為這是框架新手需要熟悉的開發人員的第乙個概念，所以學習曲線一直相當陡峭。這不再是事實。

蘋果公司的團隊為該框架引入了乙個全新的成員，這使設定和管理應用程式的核心資料棧變得輕而易舉。這個新成員是nspersistentcontainer類。

使用nspersistentcontainer類，設定核心資料棧很簡單。您可以通過呼叫init(name:)初始化程式來初始化例項。傳遞給初始化程式的名稱由永續性容器使用，以在應用程式包中查詢資料模型，並且還用於命名應用程式的永續性儲存。

永續性容器建立永續性儲存協調器，託管物件模型和託管物件上下文。它公開了幾種與core data堆疊進行互動的屬性和方法。

您可以通過nspersistentcontainer例項的viewcontext屬性訪問與應用程式主佇列關聯的託管物件上下文。顧名思義，此託管物件上下文旨在用於與應用程式使用者介面有關的任何操作。

您還可以通過persistentstorecoordinator和managedobjectmodel屬性訪問永續性儲存協調器和託管物件模型。

如果需要在後台執行core data操作，則可以通過呼叫newbackgroundcontext()工廠方法向永續性容器詢問私有受管物件上下文。對於輕量級操作，可以呼叫performbackgroundtask(_:)方法。此方法接受乙個閉包，您可以在其中使用私有管理物件上下文執行後台操作。

蘋果還引入了nspersistentstoredescription類。它封裝了用於建立和載入永續性儲存的資訊，例如永續性儲存的位置，其配置以及是否為唯讀永續性儲存。

使用nspersistentstoredescription類，將永續性儲存新增到永續性儲存協調器要nspersistentstoredescription。nspersistentstorecoordinator類定義乙個新方法addpersistentstore(with:completionhandler:)，該方法接受nspersistentstoredescription例項和乙個完成處理程式。

// create persistent store description
let persistentstoredescription = nspersistentstoredescription(url: url)
// add persistent store to persistent store coordinator
persistentcontainer.persistentstorecoordinator.addpersistentstore(with: persistentstoredescription, completionhandler:  else 
}

xcode 8還包括許多更改，這些更改大大改善了對core data的支援。 xcode現在自動為資料模型的每個實體生成nsmanagedobject子類。而不是將子類的檔案新增到專案中，而是將專案弄亂了，而是將它們新增到「派生資料」資料夾中。這意味著xcode可以確保在資料模型更改時對它們進行更新，並且開發人員無需擔心檔案。

它是如何工作的？如果在xcode 8中開啟專案的資料模型並選擇乙個實體，則會在右側的data model inspector中看到乙個新選項。「類」部分中的「**生成」欄位是我們感興趣的。

從xcode 8.1開始，此字段的值自動設定為class definition。這意味著xcode為所選實體生成nsmanagedobject子類。如果您對實體進行任何更改，則為您自動更新生成的類。您無需擔心任何事情。

您可以禁用**生成，也可以指示xcode僅為該類生成副檔名（swift）或類別（objective-c）。如果選擇後乙個選項，則負責為實體建立nsmanagedobject子類。

核心資料框架還定義了乙個新協議nsfetchedresultstype，它使在swift中使用該框架變得更加輕鬆和優雅。這就是用來為category實體建立新的託管物件的方法。

if let entity = nsentitydescription.entity(forentityname: "category", in: managedobjectcontext)

從ios 10和macos 10.12開始，每個nsmanagedobject子類都知道它屬於哪個實體。

category.entity

這意味著我們僅需要指定需要在哪個託管物件上下文中建立託管物件。

let category = category(context: managedobjectcontext)

我相信您同意這看起來更加優雅和簡潔。建立提取請求也更加容易。看下面的例子。

let fetchrequest = category.fetchrequest()

我向您展示的內容只是ios 10，tvos 10，macos 10.12和watchos 3中可用的改進的一部分。還有很多值得您探索。

最重要的公告可能是查詢世代的介紹。自從十多年前發布以來，查詢世代就解決了困擾核心資料的問題。

即使故障非常有效，並且對於框架至關重要，但如果無法再實現故障，則故障可能會出錯。可以通過刪除無法訪問的故障（即不再能滿足的故障）來避免這種情況。但這僅是一種解決方法，並且可能導致應用程式發生意外行為。

或者，應用程式可以從永續性儲存中積極獲取所需的每條資料，從而繞過故障。這會導致效能下降和更大的記憶體占用。換句話說，您禁用框架的關鍵功能之一。

查詢生成提供了另乙個解決問題根源的解決方案。這個想法很簡單。執行有點複雜。

從ios 10和macos 10.12開始，可以將查詢生成分配給託管物件上下文。這意味著被管理物件上下文與永續性儲存中儲存的資料的快照進行互動。即使其他託管物件上下文進行了更改（插入，刪除和更新），託管物件上下文的快照也保持不變。

好處是資料不能從被管理物件上下文下面更改。換句話說，受管物件上下文與特定的資料生成（即名稱查詢生成）一起使用。

受管物件上下文具有三個用於生成查詢的選項。第一種選擇不會改變任何東西。受管物件上下文不會將自身固定到查詢生成。如果永續性儲存的資料發生更改，則託管物件上下文需要進行處理。這是您習慣的行為，可能導致無法訪問的故障。

或者，受管物件上下文可以在從永續性儲存載入資料時將自身固定到查詢生成。作為第三個選項，被管理物件上下文可以將自身固定到特定的查詢生成。

儘管查詢生成是core data框架的更高階概念，但它們可以解決任何使用core data的人在某些時候都面臨的問題。您的應用程式越複雜，問題就越嚴重。很高興看到該框架現在為該問題提供了解決方案。

正如我之前提到的，對core data框架所做的改進令人驚訝。改進範圍包括新類，這些新類使使用框架的方法更易於解決永續性儲存協調器級別的效能問題。

該框架的另一項改進涉及併發性。即使不應在多個執行緒上使用永續性儲存協調器，它也知道當不同的管理物件上下文從不同的執行緒訪問永續性儲存協調器時如何鎖定自身。如果在受管理物件上下文訪問永續性儲存協調器時鎖定了該永續性儲存協調器，則其他託管物件上下文需要先等待鎖被刪除，然後它們才能訪問永續性儲存協調器。這可能會導致效能問題，並可能導致使用者介面混亂，從而導致效能下降。

從ios 10和macos 10.12開始，當託管物件上下文將更改推送到持久儲存協調器時，持久儲存協調器不再獲得鎖定。而是，永續性儲存立即將永續性儲存協調器的請求傳送到sql儲存本身。相反，該鎖定是在sql儲存級別進行的。

這種方法有幾個重要的好處。不再需要使用多個核心資料堆疊來避免效能問題。這意味著即使對於大型和複雜的應用程式，也可以顯著簡化應用程式的體系結構。

由於此解決方案是在sql儲存級別上實現的，因此僅當您的應用程式使用sqlite儲存作為其持久儲存時才可用。如果您的應用程式使用多個永續性儲存，則這些儲存中的每乙個都必須是乙個sqlite儲存。預設情況下啟用此功能。

翻譯自:

核心資料變得更好

WinPcap核心資料

核心資料結構

核心資料結構

核心資料變得更好

WinPcap核心資料

核心資料結構

核心資料結構

相關推薦