對應用程序有想法，但缺乏開始創建應用程序的編程知識？這個每週一次的博客系列“如何釋放你作為應用程序開發人員的內在潛力”，將引導您完成為 iPhone、iPod touch 和 iPad（不是程序員）創建應用程序的過程。加入我的每週冒險，您將體驗將想法變為現實的樂趣！這是該系列的第 14 部分。如果您剛剛開始，請在此處查看本系列的開頭。 （這篇文章已經更新到 Swift 1.2、iOS 8、Xcode 6.3）
Core Data 是一種允許您在 iOS 設備上存儲和檢索信息的技術。這是一種通常難以學習的高級技術，但我在這篇文章中的目標是簡化 Core Data，以便初學者輕鬆使用。
首先，讓我們看看 CoraData 是如何工作的。然後，在查看了 Apple 對 Core Data 的默認實現之後，我將向您展示如何輕鬆改進它。
核心數據和實體
如我一般 上一篇應用程序數據通常是實體的形式。 模型 模型-視圖-控制器設計模式。實體代表真實世界的對象並具有模仿真實世界對象的屬性。例如，主要目的 iApps 評論 我們正在構建的應用程序是為用戶提供一個為他們的應用程序撰寫評論的地方。如果要對此應用程序的實體進行建模 審查實體 請解釋實際審查。你可以創建 AppCategoryEntity 描述您可以分配給您的應用程序的不同類別。您也可以創建它。 用戶實體 請說明誰在使用該應用程序。
創建實體
那麼如何為您的應用創建實體呢？主要分為三個步驟。
- 在實體數據模型中建模或定義實體。
- 使用 Xcode 從數據模型中的每個實體生成實體類。
- 將代碼添加到您的應用程序以從實體類創建實體對象並使用它們。
讓我們仔細看看每一步。
使用實體數據模型為實體建模
Xcode 提供了一個可視化工具，稱為實體數據模型（或簡稱“數據模型”），您可以使用它來對應用程序的實體進行建模。例如，參見 審查實體 圖 1 所示的實體數據模型顯示在左側。
| 圖1-實體數據模型 |
該實體具有以下屬性 應用名稱, 筆記, 照片, 分數, 類別 什麼時候 審稿人如你看到的 AppCategoryEntity 什麼時候 用戶實體 它有自己的屬性，每個屬性都與 審查實體..
從實體數據模型生成實體類
實體數據模型中定義的實體不是 Swift 類。這些只是圖中定義的實體的表示。但是，應用程序需要一個實體類，因此在實體數據模型中定義實體後，下一步就是從模型中的每個實體創建一個 Swift 類，如圖 2 所示。
 |
| 圖 2-您需要從數據模型中的實體生成實體類。 |
幸運的是，正如您所見，Xcode 可以通過一個簡單的步驟完成此操作。
創建實體對象
從實體生成類後，您可以將代碼添加到應用程序以從這些實體類創建和操作對象。
例如，您可以創建一條新評論以響應用戶撰寫評論，如圖 3 所示。 審查實體 對像類別、評級、應用名稱、評論和圖像，並將它們保存在對象的屬性中。
 |
| 圖 3-您可以將用戶界面控件值保存在實體對象的屬性中。 |
將實體對象保存在數據庫中
如何保存實體，以便創建實體對象，將信息保存在其各種屬性中，然後在下次打開應用程序時再次查看評論？這就是核心數據的用武之地。
核心數據是一個實體 數據庫..大多數非程序員都熟悉術語“數據庫”，並且對以後存儲和檢索數據的地方有一個模糊的概念。讓我們仔細看看數據庫的結構。
在幕後，Core Data 為您的應用程序創建一個數據庫，並為應用程序中的每個實體添加一個表到數據庫中，如圖 4 所示。 請注意，Core Data 創建了一個與實體同名並帶有前綴“Z”的表。
 |
| 圖 4-Core Data 將實體存儲在數據庫中。 |
一個表可以包含多個相同類型的數據記錄。因此，例如，所有評論都保存在 ZREVIEWENTITY 表，所有應用程序類別都存儲在 ZAPPCATEGORYENTITY 表和用戶信息存儲在 ZUSERENTITY 桌子。
Core Data 在表中為關聯實體的每個屬性創建一列。例如，如圖 5 所示。 ZAPPCATEGORYENTITY 該表有兩列。 類別 ID 什麼時候 姓名每個屬性一個 AppCategoryEntity..
 |
| 圖 5 – Core Data 為每個實體屬性創建一個表列。 |
在圖 5 中，表有三個記錄，也稱為行。每次保存一個新的 AppCategoryEntity 對象，添加了新記錄 ZAPPCATEGORYENTITY 桌子。
Core Data 在將實體轉換為數據表中的一行數據時所做的魔術稱為對象關係映射 (ORM)。 Core Data之所以這樣稱呼，是因為它將實體對象轉化為存儲在關係數據庫中的數據（數據庫中的表之間可以有關係，所以這樣稱呼它們。增加）。 Core Data 減輕了學習複雜數據庫編程的負擔。您無需學習數據庫編程語言即可保存、檢索、更新和刪除實體。
Apple 選擇在 iOS 設備上使用的數據庫是 SQLite。緊湊型 SQLite 數據庫是世界上部署最廣泛的數據庫之一，並在其他流行的系統中使用，例如 Google 的 Android、Microsoft 的 Windows Phone 8、RIM 的 Blackberry、Nokia 的 Maemo 等。 查看有關 SQLite 的更多信息 這個鏈接..
使用對像上下文
Core Data 由 Cocoa Touch 框架中的一組類組成。使用的主要核心數據類有： NSManagedObjectContext..向對像上下文的實例發送消息以在應用程序中創建、檢索、插入、更新和刪除實體。對像上下文跟踪您獲得或創建的所有實體以及您對實體所做的更改。
對像上下文為更新實體提供了一種全有或全無的方法。當你寄出 保存實體 信息。保存所有修改的實體。沒有選項可以保存對一個或多個選定實體的更改。
在幕後，對像上下文使用持久存儲協調器對象（ NSPersistentCoordinater Class)，用於與 SQLite 數據庫通信。持久存儲協調器知道數據庫的名稱和位置。使用託管對像模型 ( NSManagedObjectModel) 了解數據模型中的所有實體及其關係。
即用型核心數據
開箱即用的核心數據模式仍然缺乏。為了說明我的意思，圖 6 在 Xcode 中創建了一個新項目並 使用核心數據 選項。
 |
| 圖 6-即用型核心數據架構 |
如你看到的， 申請委託 該對象存儲對 託管對像上下文..對像上下文使用 持久存儲協調器按順序使用 託管對像模型 從 SQLite 數據庫獲取和更新實體。
使用此默認架構，將另一個對像上下文附加到 申請委託 由應用程序中的所有視圖控制器引用。創建每個視圖控制器時 申請委託對像上下文被傳遞給控制器，控制器存儲在控制器中。 託管對像上下文 財產。最好將代碼放在視圖控制器中，向對像上下文發送消息，然後創建、檢索、更新和刪除實體。
這種方法的問題在於它違反了將應用程序拆分為以下單獨部分的規則：
- 用戶界面
- 核心邏輯
- 數據
更正式的拆分部件的方法是模型、視圖和控制器。
正如我們在上一篇文章中了解到的，視圖控制器是用戶界面的一部分。唯一屬於視圖控制器的代碼是與用戶界面相關的代碼。因此，獲取、操作和更新實體的代碼不屬於視圖控制器。
這不僅僅是像牙塔的想法。將實體操作代碼放置在用戶界面中具有實際意義，並且會使您的應用程序在未來難以擴展。例如，如果您稍後擴展您的應用程序以存儲和檢索來自 Web 的實體，您將需要在使用此 Core Data 邏輯的任何地方查找和修改。另一個例子，如果你正在創建一個 Apple Watch 應用程序，你需要將你的核心數據邏輯移動到另一個框架項目中，你可以從你的 WatchKit 應用程序和相關的 iPhone 應用程序中訪問它。
您所需要的只是一個放置封裝或隱藏用戶界面的代碼的地方。
改進的核心數據模型
那麼需要在哪裡放置實體動作代碼呢？你應該把它放在業務控制器類中！
圖 7 顯示了改進的核心數據模型。 託管對像上下文 附在 業務總監獲取和保存實體的代碼保存在 業務總監..
 |
| 圖 7-改進的核心數據架構 |
這種方法有什麼好處？
首先，將實體動作代碼封裝在業務控制器中。您現在可以將消息從視圖控制器傳遞到業務控制器以獲取和更新實體。如何獲取和更新這些實體的機制在用戶界面中是隱藏的。這意味著您以後可以在不影響用戶界面的情況下更改實體的存儲位置和存儲方法。
該模型的另一個優點是它的可重用性。通過將實體的獲取、操作和更新代碼放在業務控制器的方法中，您可以從多個視圖控制器或多個應用程序調用這些相同的方法。這就是我們所說的可重用性！
這種架構的另一個優勢可能並不明顯。如前所述，對像上下文是一個全有或全無的命題。當您請求保存更改時，您應用中的所有實體都會保存您的更改。允許每個業務控制器擁有自己的對像上下文可以讓您更好地控制實體何時以及如何存儲在數據庫中。你可以有 顧客 與業務總監 命令 業務控制器，每個都有自己的對像上下文。這使您可以獲取和更新 客戶實體 不影響物體 訂單實體 目的。
但是，您可能需要多個業務控制器來共享同一個對像上下文。正如您將在以後的文章中看到的那樣，這種架構可以做到這一點。
結論是
在這篇文章中，我介紹了許多概念基礎。我們已經看到實體數據模型、具有表、列、行和核心數據的數據庫如何處理與許多實體一起工作的繁瑣工作。在下週的帖子中，我將應用我這週學到的知識，並將核心數據添加到 iApps 評論 商業。
>> >>
