绕过上下文
当用户点击Tag Location界面中的Done按钮后，app会关闭当前界面。我们在这里来做点改进，让用户点击Done按钮后保存一个Location对象到Core Data中。
我提到过NSManagedObjectContext对象。 这是你用来与Core Data交互的对象。 它通常被描述为“scratchpad（便笺簿）”。 你首先对上下文进行更改，然后调用其save（）方法将这些更改永久的存储在数据存储中。
这意味着每个需要对Core Data做某事的对象都需要引用NSManagedObjectContext对象。
打开LocationDetailsViewController.swift，导入Core Data并且添加下面这行代码：
var managedObjectContext: NSManagedObjectContext!
问题是：如何从app的委托中放置NSManagedObjectContext对象
到这条属性？
上下文对象由AppDelegate创建，但AppDelegate没有对LocationDetailsViewController的引用。
这并不奇怪，因为在用户点击Tag Location按钮之前，Location Details视图控制器并不存在。 在启动这个转场之前，LocationDetailsViewController对象根本就不存在。
答案是在展现LocationDetailsViewController的转场期间传递NSManagedObjectContext对象。 而做这件事情最理想的地方就是CurrentLocationViewController中的prepare(for:sender:)
但是现在你需要找到一种方法来把NSManagedObjectContext对象放到CurrentLocationViewController中。
很多人会像下面这样处理：
let appDelegate = UIApplication.sharedApplication().delegate as! AppDelegate
let context = appDelegate.managedObjectContext
// 对上下文进行操作
从源代码中的任何位置，你都可以通过询问AppDelegate的managedObjectContext属性来获取对上下文的引用。 听起来像是一个很好的解决方案，对吧？
然而，突然间你的所有对象都依赖于AppDelegate。 这样会很快使你的代码变得非常混乱。
作为一个通用的设计原则，最好是让你的类之间尽量少依靠彼此。 程序的不同部分之间的交互越少，理解起来就越简单。
如果你的许多类需要联系某个共享对象，例如应用程序委托，那么你可能需要重新考虑您的设计。
一个更好的解决方案是将NSManagedObjectContext赋予每个需要它的对象。 现在，图中的所有箭头都是单向的：
使用这种架构，AppDelegate将管理的对象上下文提供给CurrentLocationViewController，而后者将在执行转场时将它传递给LocationDetailsViewController。 这种技术被称为dependency injection（依赖注入）。
这意味着CurrentLocationViewController需要拥有自己的NSManagedObject上下文属性。
打开CurrentLocationViewController.swift，添加下面这行代码，不要忘记导入Core Data框架，否则Xcode会报错。
var managedObjectContext: NSManagedObjectContext!
同时在prepare(for:sender:)中添加以下代码，这样就可以把上下文对象传递到Tag Location界面了：
override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
if segue.identifier == "TagLocation" {
...
controller.coordinate = location!.coordinate
controller.placemark = placemark
controller.managedObjectContext = managedObjectContext // 添加这一行
}
}
这也解释了为什么managedObjectContext变量被声明为类型为NSManagedObjectContext的隐式解包可选型。
你应该知道Swift中的变量必须有一个值。 如果他们可以是nil- 这意味着“没有值” - 那么变量必须是可选型的。
如果你在声明managedObjectContext的时候漏掉了最后的感叹号，比如下面这样：
var managedObjectContext: NSManagedObjectContext
那么Swift会要求你在init方法中给它一个值。 对于从storyboard加载的对象，比如视图控制器，则是init?(coder)方法。
但是，prepare(for:sender:)发生在新的视图控制器实例化之后，此时距离调用init？（coder）已经有很长一段时间了。 因此，在init？（coder）里面，你不知道managedObjectContext的值是什么。
所以你别无选择，只能将managedObjectContext变量为nil保留一段时间，直到发生转场，因此它必须是可选型的。
你也可以这样声明：
var managedObjectContext: NSManagedObjectContext?
问号和感叹号的不同是问号需要你使用if let手动解包。
这有点烦人，特别是当你知道managedObjectContext将在转场期间将得到一个合适的值，并且它将永远不会再成为nil。 在这种情况下，感叹号是最佳选择。
这些关于可选型的规则可能看起来非常严格 - 而且可能会让人困惑，这些规则是有原因的。 通过只允许某些变量没有值，Swift可以使你的程序更安全，减少编程错误的次数。
可选型使用的越少越好，但是有些情况下你不可避免的要使用它，比如现在的managedObjectContext。
AppDelegate.swift现在需要一些方法将NSManagedObjectContext对象传递给CurrentLocationViewController。
不幸的是，界面建造器（Interface Builder）不允许你在App Delegate上为你的视图控制器制作插件。 你必须通过storyboard来查看这些视图控制器。
将application(didFinishLaunchingWithOptions) 方法修改为下面这个样子：
func application(_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions:
[UIApplicationLaunchOptionsKey: Any]?)
-> Bool {
let tabBarController = window!.rootViewController
as! UITabBarController
if let tabBarViewControllers = tabBarController.viewControllers {
let currentLocationViewController = tabBarViewControllers[0]
as! CurrentLocationViewController
currentLocationViewController.managedObjectContext =
managedObjectContext
}
return true
}
为了获得CurrentLocationViewController的引用，你首先必须找到UITabBarController，然后查看其中的viewControllers数组。
一旦你有了一个对CurrentLocationViewController对象的引用，就给它一个managedObjectContext。 代码上可能没有明显的体现这一点，但是这里确实发生了一些特殊的事件。
还记得之前添加到AppDelegate的persistentContainer代码吗？ 这是它的样子（我省略了大部分代码）：
lazy var persistentContainer: NSPersistentContainer = { let container = . . .
...
return container
}()
你可能认识到这是一个封闭。 你已经看过几次了。 通常情况下，封闭包含不会马上执行的源代码，因此您可以将其存储起来以备后用。 然而在这里，结束处的括号会立即调用它。
为了解释清楚，我们举一个栗子：
var four: Int = { return 2 + 2 }()
这个变量的初始值是{return 2 + 2}，也就是4。 这样做有点蠢，但是对于persistentContainer来说这样做真的很方便。
闭包内实际发生的事情相当简单：
let container = NSPersistentContainer(name: "DataModel")
container.loadPersistentStores(completionHandler: {
storeDescription, error in
if let error = error {
fatalError("Could load data store: \(error)")
}
})
return container
你使用之前创建的数据模型“DataModel”实例化新的NSPersistentContainer对象。 然后将其告知loadPersistentStores（），它将数据库中的数据加载到内存中，并设置Core Data堆栈。
这里还有另一个闭包，由completionHandler参数给出。 当持久化容器完成加载数据时，将调用此闭包中的代码。 如果出现问题，将打印一条错误消息，并使用函数fatalError（）终止应用程序。这对于调试非常有用！
现在你知道它做了什么，你可能还想知道为什么你不只是把所有的代码放到一个常规的方法中，像下面这样：
var persistentContainer: NSPersistentContainer
init() {
persistentContainer = createPersistentContainer()
}
func createPersistentContainer() -> NSPersistentContainer {
// all the initialization code here
return container
}
这当然是可以的，但是现在，persistentContainer的初始化分布在代码的三个不同部分：变量的声明，执行所有初始化逻辑的方法以及将所有初始化逻辑联系在一起的init方法。将所有这些东西放在一个地方不是更好，而不是把它们切成三块。
这里还有一件事情需要注意：
lazy var persistentContainer: NSPersistentContainer = { . . . }()
注意到lazy关键字了吗？ 这意味着{。。。 }（）闭包实际上不是马上执行的。 上下文对象将不会被创建，直到你要求创建。 这是延迟加载的另一个例子，就像你使用DateFormatter所做的一样。
managedObjectContext属性同样也是lazy性质的：
lazy var managedObjectContext: NSManagedObjectContext = self.persistentContainer.viewContext
这是非常必要的，因为它的初始值来自persistentContainer。 这里也必须使用self来指代persistentContainer。 如果没有，Xcode会给出了一个报错。
运行应用程序。 看起来不会有什么变化，但幕后的Core Data创建了一个新的数据库。
窥视一下数据存储的内部
如前所述，Core Data将数据存储在SQLite数据库中。 该文件名为DataModel.sqlite，它位于app的库文件夹中。 这与你在上一个教程中看到的Documents文件夹类似。
如果你去〜/ Library / Developer / CoreSimulator，然后到包含MyLocations应用程序数据的文件夹，你可以在Finder中看到它。
找到这个文件夹最简单的方法是将下面的代码添加到Functions.swift中：
let applicationDocumentsDirectory: URL = {
let paths = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask)
return paths[0]
}()
这里创建了一个新的全局常量applicationDocumentsDirectory，其中包含app的Documents目录的路径。 这是一个全局性的常量，因为你没有把它放在某个类中。 这个常量将在app的运行时间内存在; 你也可以像在Checklists教程中那样做一个方法，但是使用全局常量也是一样的。
和以前一样，使用闭包来提供初始化这个常量的代码。
⚠️：全局变量的声誉很差。 许多程序员不惜一切代价避免它们。 全局变量的问题在于它们在程序的各个部分之间创建隐藏的依赖关系。 依赖性使程序难以改变，难以调试。
但是用得好，全局变量可以非常方便。比如你的app需要知道几个不同位置的Documents目录的路径， 把它放在全局常量中是解决这个问题的好方法。
在application(didFinishLaunchingWithOptions)中添加下面这行代码：
print(applicationDocumentsDirectory)
在我的电脑上，打印结果是这样的：
file:///Users/matthijs/Library/Developer/CoreSimulator/Devices/66422991-
21E3-4394-8DCE-0584865EA854/data/Containers/Data/Application/998845B1-
8E87-40F7-9C3E-FC8DE517227D/Documents/
打开一个新的Finder窗口，然后使用快捷键Shift+command+G，然后把这段路径拷贝到file://后面，就可以打开这个文件夹了。
数据库实际上不在“Documents”文件夹中，因此请返回一级，然后进入“Library”文件夹“Application Support”：
DataModel.sqlite-shm和-wal文件也是数据存储的一部分。
这个数据库仍然是空的，因为你还没有存储任何对象。
有几个方便的（free）工具，为你提供一个图形界面与SQLite数据库交互。
在本节中，你将使用Liya来检查数据存储文件。 从Mac App Store或www.cutedgesystems.com/software/liya/下载。（这个软件的美工不忍直视，所以你不用怀疑自己看到的图标，只管下载就行了）
启动Liya后，它会问你要数据库的连接。将Database Type选项，选择为SQLite。
Database Type的右边有一个不起眼的图标，点击它，可以选择打开哪个数据库文件。
你可以输入CoreSimulator/.../Library/Application Support文件夹地址，但是这样很容易弄错。
比较好的方式是在Finder中找到数据库文件，然后右键使用Liya打开。
打开后你会看到下面这样的界面：
ZLOCATION表是你的Location对象将被存储的地方。 它目前是空的，但在右侧，你已经可以看到与你的字段对应的列名：ZDATE，ZLATITUDE等等。 Core Data还添加了自己的列和表（带有Z_前缀）。
你并不是应该手动改变这个数据库中的任何东西，但是有时候使用这样的可视化工具可以方便地看到发生了什么。 插入新的位置对象后，我们将回到Liya再看看发生了什么。
⚠️：Liya的替代品是SQLiteStudio。 你可以通过搜索“sqlite”在Mac App Store上找到更多付费和免费的工具。
还有一个方便的Core Data故障排除工具。 通过在app上设置一个特殊标志，您可以看到Core Data在内部使用的SQL语句与数据存储区的交互情况。
即使你没学过SQL，这仍然是有价值的信息。 至少你可以用它来判断Core Data是否在做某事。 要启用此工具，你必须编辑工程的scheme。
Scheme是Xcode让你配置你的项目。 一个scheme是一堆构建和运行你的app的设置。 标准项目只有一个scheme，但你可以添加额外的scheme，这在你的项目变大时非常方便。
点击屏幕顶部MyLocations> iPhone栏的左侧部分，然后从菜单中选择Edit Scheme ...。
应该会弹出这样一个界面：
选择左边的Run选项。
然后选择Arguments子页。
然后找到Arguments Passed On Launch分节，添加下面两项：
-com.apple.CoreData.SQLDebug 1
-com.apple.CoreData.Logging.stderr 1
然后点击Close关闭对话框，运行app。
你应该可以在调试区域看到下面这样的信息：
CoreData: annotation: Connecting to sqlite database file at "/Users/
matthijs/Library/Developer/CoreSimulator/Devices/66422991-21E3-
4394-8DCE-0584865EA854/data/Containers/Data/Application/998845B1-8E87-
40F7-9C3E-FC8DE517227D/Library/Application Support/DataModel.sqlite"
CoreData: sql: SELECT TBL_NAME FROM SQLITE_MASTER WHERE TBL_NAME =
'Z_METADATA'
CoreData: sql: pragma journal_mode=wal
CoreData: sql: pragma cache_size=200
CoreData: sql: SELECT Z_VERSION, Z_UUID, Z_PLIST FROM Z_METADATA
这是Core Data的调试输出。 如果你懂SQL，其中一些内容看起来很熟悉。 具体细节并不重要，但很显然，Core Data现在正在连接到数据存储。 非常不错。
