padrão de design para Core Data iPhone App

Question

Im construção de um aplicativo que irá usar um modelo Core Data. I muito novo em Objective C e os meus padrões de projeto usuais não se aplica realmente em Core Data e Objective C, pelo menos eu não consigo encontrar exemplos que confirma que eles vão.

Já passei os exemplos Apple Developer e diferentes fontes sobre as intertubes.

Parece que a alavancagem Core Data I necessidade de passar a managedObjectContext para cada um dos meus viewControllers, têm a viewController implementar o NSFetchedResultsControllerDelegate e depois implementar cada um dos métodos para fazer uma busca e, posteriormente, implementar

NSFetchedResultsChangeInsert

NSFetchedResultsChangeDelete NSFetchedResultsChangeMove NSFetchedResultsChangeUpdate

Isso adiciona cerca de 100 + linhas de código em cada viewController e é 90% o mesmo código que eu escrevo de novo e de novo. Além disso, eu tenho que passar tudo ao seu redor e acompanhar a sua pegada de memória.

Em outras línguas que eu iria construir um modelo singleton de algumas classes que métodos para manter e fornecer dados a pedido, disponível a partir de qualquer lugar mantidos. Parece que eu não posso tomar essa abordagem em Objective C. Se eu onde para construir uma classe estática que tomou um managedObjectContext e me devolveu o que eu precisava, eu ainda teria que passar o managedObjectContext em torno de cada ponto de vista e não seria de forma assíncrona como quando eu implementar métodos de delegado que só é chamado quando o resultado está pronto.

Espero que isso faz sentido e que alguém pode confirmar que não há outra maneira razoável de fazê-lo ou ajudar a apontar-me em uma direção para embrulhar isto em um bom caminho.

Obrigado:)

Answer 1

Não

Core Data é quase tão complicado como você descreve.

Geralmente, um aplicativo para iPhone tem um "principal" contexto de objeto gerenciado, que geralmente é de propriedade do delegado do aplicativo. Contanto que você pode obter o delegado app (dica: [[UIApplication sharedApplication] delegate]) você tem acesso ao contexto de objeto gerenciado. Eu gosto de definir uma variável global estática para manter uma referência ao meu delegado app para tornar a vida mais fácil.

Há geralmente uma correspondência de um-para-um entre instâncias NSFetchedResultsController e instâncias UITableView. Além de preencher vistas de tabela, é extremamente raro que você precisaria de um NSFetchedResultsController. Se você tem um número de pontos de vista semelhantes (por exemplo, uma barra de abas, que permite ver os mesmos dados de maneiras diferentes a la o iPod app), caberia para criar uma única classe base que configura o NSFetchedResultsController e derivar seus controladores de vista específico a partir daí.

Agora, quando você cria controladores de vista para editar um objeto, é geralmente uma boa idéia para fazer isso em um contexto separado objeto gerenciado. Se o usuário cancela, você simplesmente descartar o contexto e as mudanças vão embora. Mais uma vez, você realmente não precisa de um NSFetchedResultsController para isso, porque essas visões estão preocupados apenas com um único objeto.

Quando você estiver edição feito, você save: contexto do objeto gerenciado. Os objetos que gerenciam seus outros contextos objeto gerenciado deve implementar os métodos NSFetchedResultsControllerDelegate para manter a exibição de tabela em sincronia. Novamente, isso pode ser implementado em uma classe base para que possa generalizar essa funcionalidade para controladores de vista relacionados.

Answer 2

Você absolutamente tem que usar um modelo CoreData, ou seria algo usando um NSCoder (NSArchiver, NSKeyedArchiver, etc) de trabalho? Descobri que CoreData é um exagero para a maioria das aplicações.

Além disso, você pode esclarecer por que você não pode ter uma abordagem usando singletons? Eu usei Singleton fábricas em um número de aplicações sem problemas. É bastante fácil de definir métodos de nível de classe que operam em uma (Singleton) instância compartilhada.