Cómo conectar CoreData y Combine en MVVM

Contenido del curso

No sé dónde empezar

Introducción al Patrón MVVM

Estructura de un Proyecto con MVVM

Operaciones CRUD en un proyecto con MVVM

Clean Architecture

MVVM y Clean Architecture

28
Resumen de Clean Architecture y MVVM
06:29 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0023:11

Cómo conectar CoreData y Combine en MVVM

Curso de Patrones MVVM en iOS

Clase 10 de 28

Clase 10 / 28

Recursos

Construir un ViewModel reactivo en Swift te permite conectar el modelo de datos con la interfaz sin actualizar nada a mano. Aquí verás cómo armar un ToDoViewModel usando Combine y Core Data dentro de una arquitectura MVVM, paso a paso, para que cualquier cambio en tus tareas se refleje al instante en la vista.

Por qué usar Combine como puente entre vista y modelo

Combine es el framework de Apple que maneja datos de forma reactiva. En lugar de refrescar la pantalla manualmente cada vez que cambia una tarea, suscribes la vista a un dato observable y las actualizaciones ocurren solas [00:25].

En una arquitectura MVVM tienes tres capas: el modelo (los datos), la vista (lo que ves) y el view model (el intermediario que comunica ambos). Combine vive justo en ese intermediario.

¿Qué hace Combine en un ViewModel? Permite que las propiedades marcadas como publicadas notifiquen a la vista cualquier cambio, sin que tú escribas código extra para refrescar la UI.

Qué importaciones necesita el ViewModel

Dentro del archivo ToDoViewModel.swift necesitas tres importaciones clave [01:30]:

Foundation: herramientas base de Swift.
CoreData: el framework para almacenar datos de forma local.
Combine: para manejar datos reactivos.

La clase se declara como public final class ToDoViewModel: ObservableObject. Ese conformismo a ObservableObject es lo que permite que las vistas se suscriban a los cambios de sus propiedades publicadas.

Cómo declarar propiedades publicadas y persistencia

La propiedad central del ViewModel es la colección de tareas. Se declara como un array vacío de tipo ToDoEntity, que es la entidad de Core Data donde vive la estructura de cada tarea [02:50].

Para que cualquier cambio en esa lista se propague automáticamente a la vista, se anota con @Published. Esa anotación es justo lo que conecta Combine con SwiftUI: si agregas, eliminas o modificas un to-do, la vista se redibuja sola.

swift @Published var todos: [ToDoEntity] = [] var cancellables: Set<AnyCancellable> = [] let storeContainer: NSPersistentContainer = ToDoPersistentManager.sharedContainer

La variable cancellables es un Set<AnyCancellable> y sirve para evitar fugas de memoria, cancelando suscripciones cuando ya no las necesitas [04:20]. El storeContainer es de tipo NSPersistentContainer y accede al contenedor compartido del ToDoPersistentManager, que es donde vive la base de datos local.

Cómo cargar las tareas al inicializar

En el init() se llama a fetchTodos(), así cuando creas una instancia del ViewModel ya tienes todas las tareas cargadas [05:50].

La función fetchTodos usa NSFetchRequest<ToDoEntity> para consultar Core Data. Para ordenar los resultados se usa un NSSortDescriptor con la key date y ascending: true, lo que devuelve las tareas ordenadas cronológicamente [07:00].

También se asigna request.returnsObjectsAsFaults = false para evitar cargar objetos fallidos y obtener acceso completo a los datos. Todo esto va envuelto en un do-catch que imprime un mensaje si falla la recuperación.

swift let request: NSFetchRequest<ToDoEntity> = ToDoEntity.fetchRequest() let sortDescriptor = NSSortDescriptor(key: "date", ascending: true) request.sortDescriptors = [sortDescriptor] request.returnsObjectsAsFaults = false do { todos = try storeContainer.viewContext.fetch(request) } catch { print("Error al recuperar todos") }

Qué métodos auxiliares necesita el ToDoViewModel

Más allá de listar tareas, el ViewModel necesita métodos para guardar, validar y localizar elementos.

El método privado saveData() llama a storeContainer.viewContext.save() dentro de un do-catch y luego ejecuta fetchTodos() para refrescar la lista [10:00]. Como todos está marcado con @Published, ese refresh se propaga solo a la vista.

¿Por qué llamar a fetchTodos después de guardar? Porque al modificar la propiedad publicada, Combine notifica a la vista y el cambio aparece sin código adicional.

Cómo encontrar el índice de una tarea

La función privada getTodoIndex(of:) recibe un ToDoEntity y devuelve el índice donde se encuentra dentro del array todos [11:40]. Usa firstIndex(where:) comparando el id del elemento con el del parámetro.

Si no lo encuentra, devuelve nil. Si lo encuentra, devuelve un entero con la posición.

Cómo validar el texto antes de guardar

La función pública validateInputs(of text: String) -> Bool aplica trimmingCharacters(in: .whitespaces) para eliminar espacios en blanco y luego cuenta los caracteres restantes [13:10]. Si el conteo es mayor a cero, retorna true; en caso contrario, false.

Esta validación es útil sobre todo para el título de la tarea, evitando que entren cadenas vacías o solo con espacios.

Qué funciones públicas expone el ViewModel

Para cubrir altas, bajas y modificaciones, el ViewModel declara varias funciones públicas que se implementarán después [14:30]:

addTodo: crea una tarea nueva.
updateTodo: actualiza el título o descripción.
updateTodoStatus: cambia el estado entre completado y no completado.
deleteTodo: elimina una tarea.
archiveTodo: archiva una tarea.
unarchiveTodo: la desarchiva.

Con este conjunto, el ViewModel cubre todo el ciclo de vida de una tarea dentro de la base de datos local.

La pieza que falta es conectar la vista con este ViewModel para consumir los datos de forma reactiva. ¿Cómo crees que SwiftUI debería suscribirse a @Published para mostrar la lista? Cuéntame en los comentarios.

Resumen

Por qué usar Combine como puente entre vista y modelo

En una arquitectura MVVM tienes tres capas: el modelo (los datos), la vista (lo que ves) y el view model (el intermediario que comunica ambos). Combine vive justo en ese intermediario.

¿Qué hace Combine en un ViewModel? Permite que las propiedades marcadas como publicadas notifiquen a la vista cualquier cambio, sin que tú escribas código extra para refrescar la UI.

Qué importaciones necesita el ViewModel

Dentro del archivo ToDoViewModel.swift necesitas tres importaciones clave [01:30]:

Foundation: herramientas base de Swift.
CoreData: el framework para almacenar datos de forma local.
Combine: para manejar datos reactivos.

Cómo declarar propiedades publicadas y persistencia

La propiedad central del ViewModel es la colección de tareas. Se declara como un array vacío de tipo ToDoEntity, que es la entidad de Core Data donde vive la estructura de cada tarea [02:50].

swift @Published var todos: [ToDoEntity] = [] var cancellables: Set<AnyCancellable> = [] let storeContainer: NSPersistentContainer = ToDoPersistentManager.sharedContainer

Cómo cargar las tareas al inicializar

En el init() se llama a fetchTodos(), así cuando creas una instancia del ViewModel ya tienes todas las tareas cargadas [05:50].

Qué métodos auxiliares necesita el ToDoViewModel

Más allá de listar tareas, el ViewModel necesita métodos para guardar, validar y localizar elementos.

¿Por qué llamar a fetchTodos después de guardar? Porque al modificar la propiedad publicada, Combine notifica a la vista y el cambio aparece sin código adicional.

Cómo encontrar el índice de una tarea

Si no lo encuentra, devuelve nil. Si lo encuentra, devuelve un entero con la posición.

Cómo validar el texto antes de guardar

Esta validación es útil sobre todo para el título de la tarea, evitando que entren cadenas vacías o solo con espacios.

Qué funciones públicas expone el ViewModel

Para cubrir altas, bajas y modificaciones, el ViewModel declara varias funciones públicas que se implementarán después [14:30]:

addTodo: crea una tarea nueva.
updateTodo: actualiza el título o descripción.
updateTodoStatus: cambia el estado entre completado y no completado.
deleteTodo: elimina una tarea.
archiveTodo: archiva una tarea.
unarchiveTodo: la desarchiva.

Con este conjunto, el ViewModel cubre todo el ciclo de vida de una tarea dentro de la base de datos local.

Oscar Gutiérrez

Hace 2 años

Estuve revisando un post de apple: Migración del protocolo Objeto Observable a la macro Observable

Si bien parece que el código queda un poco mas simple aun me queda la duda de si: ¿solo es una abstracción o cual es la diferencia en si?

Ricardo Ivan Herrera Rocha

Hace un año

Hola Oscar,

La nueva macro @Observable en Swift (presentada en Swift 5.9) no es solo una abstracción del protocolo ObservableObject, aunque comparten el objetivo de permitir la observación de cambios en datos.

Aquí te resumo las principales diferencias:

Simplificación de código

Con ObservableObject, necesitas:
- Conformar manualmente al protocolo.
- Marcar cada propiedad con @Published.
- Usar Combine y suscripciones internas si quieres reaccionar a cambios.

en swift class UserModel: ObservableObject {

@Published var name: String = ""

}

Con @Observable, Swift genera automáticamente todo esto por ti. Solo declaras las propiedades, y ya son observables:

@Observable

class UserModel {

var name: String = ""

}

Menos dependencias de Combine

@Observable no requiere Combine.
Esto lo hace más liviano, eficiente y preparado para trabajar de manera nativa con SwiftUI moderno.

Más rendimiento

Al ser una macro, el compilador genera código más optimizado detrás de cámaras.
Menos runtime, más compile-time → mejor rendimiento.

Migración progresiva

Apple recomienda migrar hacia @Observable en nuevos proyectos o cuando te beneficie la simplificación, pero ambos siguen funcionando (por ahora).

En resumen: @Observable no es solo una abstracción, sino una evolución del patrón, con menos código, sin necesidad de Combine y mejor rendimiento. Ideal para nuevos proyectos con Swift moderno y SwiftUI.

Introducción al Patrón MVVM

Implementación de MVVM en Swift: Organiza y Optimiza tus Apps

Patrones de Arquitectura y Diseño en Desarrollo de Software iOS

MVC vs MVP en iOS: diferencias clave

Qué son los principios SOLID

MVVM y SOLID en SwiftUI

Estructura de un Proyecto con MVVM

Proyecto MVVM en Swift: Buenas Prácticas y Configuración Inicial

Cómo crear el modelo Item con MVVM en Swift

Modelo de datos con Core Data en Swift

Vistas en MVVM con SwiftUI

Cómo conectar CoreData y Combine en MVVM

Operaciones CRUD en un proyecto con MVVM

Función addTodo con Core Data en SwiftUI

Funcionalidades básicas para gestionar tareas en SwiftUI

Listado y detalle de notas en SwiftUI

Editar todos con SwiftUI y Core Data

Archivar tareas en SwiftUI con Core Data

Cómo desarchivar tareas con unarchiveTodo

Eliminar un to do definitivamente con Core Data

Marcar tareas completadas en SwiftUI

Creación de Vistas Amigables en SwiftUI para Aplicaciones de Tareas

Clean Architecture

Qué es Clean Architecture y por qué supera a MVVM

Estructura y Ventajas de la Clean Architecture

Estructura de proyecto iOS con Clean Architecture

Mapeo de JSON a structs Swift con Codable

Capa de datos con Clean Architecture en Swift

Casos de uso en la capa de dominio Swift

Capa de presentación con MVVM en SwiftUI

Navegación y detalle con Clean Architecture en SwiftUI

MVVM y Clean Architecture

Resumen de Clean Architecture y MVVM

Cómo conectar CoreData y Combine en MVVM