Lib*_*tal 2 singleton core-data nsmanagedobjectcontext ios swift
我已经看过很多教程,他们真的帮助我了解父子管理对象上下文以及与此相关的其他事情.我准备开始在我的应用程序中使用它,但我有一个问题.为什么没有人使用单例来保持主要的托管对象上下文.我想从AppDelegate中提取Core Data相关对象并将其设置为自己的类更好?像raywenderlich.com这个教程中的内容.但是他们仍然实例化CoreDataStack类(没有问题,单例也必须实例化)并且当需要时他们在prepareForSegue中设置managedObjectContext(并将其设置为来自AppDelegate的第一个视图控制器).为什么不删除这个需求,只使用单例CoreDataStack,并且如果需要可以在每个控制器中使用managedObjectContext?
第二个和奖金问题:我认为最好在控制器中使用更少的代码,在其他类中使用更多的代码.我认为这有助于提高可读性.那么如果我从控制器移动此代码并将其设置为CoreDataStack类或其他一些有助于核心数据请求和响应的类,该怎么办?
func surfJournalFetchRequest() -> NSFetchRequest {
let fetchRequest =
NSFetchRequest(entityName: "JournalEntry")
fetchRequest.fetchBatchSize = 20
let sortDescriptor =
NSSortDescriptor(key: "date", ascending: false)
fetchRequest.sortDescriptors = [sortDescriptor]
return fetchRequest
}
Run Code Online (Sandbox Code Playgroud)
我知道这是可能的,但它更好吗?如果您从我那里获得应用程序代码,那么如果在控制器中它会是一行会更好CoreDataStack.fetchRequest("JournalEntry", sortedKey: "date")
吗?
如果我接受这个代码并将其插入单例并使用闭包创建函数呢?我会在单例中创建子管理上下文并在那里做必要的操作,在控制器中我只会更改UI:
func exportCSVFile() {
navigationItem.leftBarButtonItem = activityIndicatorBarButtonItem()
let privateContext = NSManagedObjectContext(concurrencyType: .PrivateQueueConcurrencyType)
privateContext.persistentStoreCoordinator = coreDataStack.context.persistentStoreCoordinator
privateContext.performBlock { () -> Void in
var fetchRequestError:NSError? = nil
let results = privateContext.executeFetchRequest(self.surfJournalFetchRequest(), error: &fetchRequestError)
if results == nil {
println("ERROR: \(fetchRequestError)")
}
let exportFilePath = NSTemporaryDirectory() + "export.csv"
let exportFileURL = NSURL(fileURLWithPath: exportFilePath)!
NSFileManager.defaultManager().createFileAtPath(exportFilePath, contents: NSData(), attributes: nil)
var fileHandleError: NSError? = nil
let fileHandle = NSFileHandle(forWritingToURL: exportFileURL, error: &fileHandleError)
if let fileHandle = fileHandle {
for object in results! {
let journalEntry = object as! JournalEntry
fileHandle.seekToEndOfFile()
let csvData = journalEntry.csv().dataUsingEncoding(NSUTF8StringEncoding, allowLossyConversion: false)
fileHandle.writeData(csvData!)
}
fileHandle.closeFile()
dispatch_async(dispatch_get_main_queue(), { () -> Void in
self.navigationItem.leftBarButtonItem =
self.exportBarButtonItem()
println("Export Path: \(exportFilePath)")
self.showExportFinishedAlertView(exportFilePath)
})
} else {
dispatch_async(dispatch_get_main_queue(), { () -> Void in
self.navigationItem.leftBarButtonItem = self.exportBarButtonItem()
println("ERROR: \(fileHandleError)")
})
}
}
}
Run Code Online (Sandbox Code Playgroud)
我只是想确保我的方法没问题,并且会比原来更好.谢谢
Mat*_*uch 11
我用单例模式构建了我的第一个核心数据应用程序.这对我来说似乎合乎逻辑,因为无论如何只有一个核心数据堆栈.我错了,单身模式很快变成了一团糟.我添加了越来越多的代码来将单例堆栈弯曲成有效的东西.最后我放弃了,我投入时间用依赖注入取代单身人士的混乱.
以下是我在转储单例之前遇到的一些问题:
由于应用程序保留了重要数据,我的用户请求了备份功能.要从备份恢复,我切换了sqlite文件,然后我只创建一个新的核心数据堆栈.如果使用pull-pattern从单例中获取managedObjectContext,则几乎不可能以干净的方式执行此操作.所以我切换核心数据堆栈的方法是告诉用户他们必须重新启动应用程序.其次是exit()
.不是最优雅的方式来处理这个问题.
在Apple添加了childContexts之后,我决定摆脱撤销管理器和上下文回滚,因为这对我来说从未100%工作过.但是改变我的编辑viewControllers使他们使用在用户点击时丢弃的子上下文,这cancel
是一个令人难以置信的痛苦行为,因为我现在在一个viewController中混合了单例上下文和viewController本地上下文.
为了编辑关系的目标,我在editViewController中有editViewControllers.因为我在编辑viewControllers中创建了编辑上下文,所以我最终将数据保存到了本不应该保存的主上下文中.解释起来有点复杂,但第二个viewController将新对象保存到主上下文中,即使外部编辑viewController中的用户命中取消也是如此.这总是会导致孤儿.所以我添加了更多的代码来弯曲单例,使其不再是单例.
我还有CSV导入功能,我想在按"导入"之前向用户预览数据.我为此建立了一个全新的基础设施.首先,我将CSV解析为基本上复制了我的核心数据类的数据结构.然后我构建一个viewController来显示这些非核心数据类,甚至更多的代码重复.我只会在用户按下导入时开始创建核心数据对象.
摆脱单例模式后,我可以重用现有的数据显示viewController.我只是给它一个不同的上下文,在这种情况下是一个内存上下文,其中包含将被导入的数据.更清晰,更少重复的代码.
我猜其中一些问题并不是单身人士的错.我只是非常缺乏经验.
但我仍强烈建议不要使用单身核心数据.
会是一条线
CoreDataStack.fetchRequest("JournalEntry", sortedKey: "date")
吗?
你不需要单身人士.像这样的东西应该是你为JournalEntry创建的NSManagedObject子类.
如果我接受这个代码并将其插入单例并使用闭包创建函数呢?我会在单例中创建子管理上下文并在那里做必要的操作,在控制器中我只会更改UI:
为什么不创建一个根本不需要内部状态的方法?
class func export(#context: NSManagedObjectContext, toCSVAtPath path: String,
progress: ((current: Int, totalCount: Int) -> Void)?,
completion: ((success: Bool, error: NSError?) -> Void)?) {
Run Code Online (Sandbox Code Playgroud)
更加灵活.
归档时间: |
|
查看次数: |
3978 次 |
最近记录: |