Desbravando o Core Data Stack…
Construir um projeto com core data pode parecer simples mas entender tudo o que está acontecendo por detrás dos panos pode chegar a dar um nó na cabeça! 🤯 O objetivo deste post não é ensinar a criar uma aplicação com core data mas sim, te ajudar a entender o básico para iniciar sua jornada neste framework com o pé direito. Então, vamos colocar um pouco de teoria nessa prática.
Antes de tudo, um breve aviso é que este post tem foco no Persistence Store com SQLite e caso ainda não saiba o que isso significa, não tem problema, continue a leitura e logo saberá. 📌
Para começo de conversa, vamos definir o que exatamente é o Core Data. Bom, vale ressaltar que ele não é um banco de dados. Core Data é um framework nativo da Apple usado para persistir localmente os dados do seu aplicativo. De que forma? Basicamente, ele cria uma camada de abstração dos detalhes de mapeamento dos objetos que estão no banco de dados, em outras palavras, é um gerenciador de grafo de objeto que retira a necessidade de acessar o banco de dados diretamente e facilita a manipulação dos dados. Isso mesmo, para utilizar o core data não é necessário saber SQL pois é ele que fica responsável pela interação direta com o banco.
Há muitas coisas interessantes sobre o core data e uma delas é a sua estrutura. Ele possui uma stack que dá suporte ao modelo da sua aplicação e consiste em três objetos: managed object model, managed object context e persistent store coordinator. Cada um possui uma responsabilidade diferente e se relacionam entre si (como mostrado na imagem abaixo). Dito isto, vamos entender um pouco mais desta stack.
📍 Data Model:
É o modelo de entidades com suas devidas propriedades e relacionamentos e que muito se assemelha com o esquema do banco de dados. Dentro do XCode, é representado por um arquivo que descreve os dados da sua aplicação graficamente e cuja extensão é .xcdatamodeld:
📍 Managed Object Model:
É uma coleção de descrições de entidade. Ele carrega o data model, de forma que as entidades ficam apresentáveis a stack como classes, bem com os respectivos atributos e relacionamentos. É através dele que o Persistence Store Coordinator pode verificar se o Persistence Store está de acordo com o modelo da aplicação. O modo como trabalhamos no Core Data é orientado à objetos e isto fica claro quando atentamos para estrutura desta classe.
📍 Managed Object Context:
O managed object context é a primeira camada acima do banco, onde são abstraídos os dados para manipulação, há aplicativos que possuem mais de um contexto. É aqui onde ficam as operações como deleções, modificações e etc, que ficam apenas na memória até que você as salve (pode ser usada a função saveContext que dependendo das configurações da aplicação é gerada automaticamente no appDelegate) e somente assim, serão mandadas para o Persistence Store (SQLite). É ele que contém uma referência para o Persistente Store Coordinator.
📍 Persistence Store Coordinator:
Contém uma referência para o Managed Object Model e ao Managed Object Context . Ele é responsável pela persistência do aplicativo mais diretamente (em relação a ser uma camada mais próxima do banco de dados). É a ele que são solicitados pelo Managed Object Context os dados que vêm do persistence store e assim são trazidos, bem como também podem ser enviadas para ele as mudanças dos dados feitas no contexto e, a partir dele, de volta para o persistence store. Em outras palavras, é responsável pela coordenação dos dados que serão persistidos assim como a sua nomenclatura define.
📍 Persistence Store
De acordo com a documentação da Apple, o persistence store é um repositório que armazena os objetos que estão sendo gerenciados. É como um arquivo de dados do banco de dados que salva as últimas alterações do objeto, ficando entre o Persistence Store Coordinator e o estado permanente do grafo do objeto que será lido e gravado. Há três tipos de arquivos nativos para o persistence store com base em disco, são eles: XML, Binary e SQLite, e um armazenamento in Memory.
-
Binary: Este tipo de armazenamento precisa ser carregado na memória antes de alguma operação de leitura e gravação. Costuma ocupar menos espaço em disco, tem um rápido carregamento e o grafo de objetos é carregado inteiramente na memória.
-
SQLite: Este armazenamento vai carregando blocos do grafo de objetos na memória de acordo com o solicitado. É o default usado pelo Core Data. Carrega rapidamente, embora seja interessante lembrar que a estrutura de aplicativos que utilizam esse tipo de armazenamento sejam normalmente de grande conjunto de dados, pois com ele o grafo do objeto reside parcialmente na memória.
-
XML: É semelhante ao Binary e é guardado em um formato legível, o que facilita na hora de inspecionar o arquivo mas também o torna mais lento. Ele não é compatível com IOS.
-
In-memory: Como o nome sugere, este armazenamento também é carregado inteiramente na memória, é rápido e nenhum armazenamento em disco é necessário.
Quanto ao desempenho, utilizar um ou outro tipo de armazenamento vai depender muito da sua aplicação.
Depois de toda essa informação, quero te dar mais uma motivação para continuar desbravando o Core Data, entre as vantagens que ele possui aí vão as principais:
- É framework nativo que possui um suporte dado pela própria Apple
- Fácil gerenciamento, facilitando operações de buscas complexas
- Possui integração com o CloudKit, o que facilita um backup de dados na nuvem
Então, é isto! Vou ficando por aqui mas espero que as coisas façam um pouco mais de sentido agora e que tenha contribuído para seus estudos.