Contenido del curso
Arquitectura
Gestión de Datos en SwiftData
- 8

Uso de SWIFTDA para Persistencia de Datos en iOS 17
04:31 min - 9

Cómo grabar datos con SwiftData
10:55 min - 10

Implementación de Queries con Predicados en Swift Data
11:08 min - 11

Corrección automática y actualización de registros en SWIFTDA
06:59 min - 12

Eliminar registros y calcular totales en SwiftData
04:20 min
Gestión de Datos en Realm
¿Swift Data o Realm?
Arquitectura MVVM con protocolos en Swift
Resumen
Diseñar una arquitectura sólida antes de escribir código marca la diferencia entre un proyecto que escala y uno que se rompe al primer cambio. Aquí verás cómo estructurar una app en Swift usando MVVM con protocolos de servicio que permiten intercambiar bases de datos como SwiftData y Realm sin tocar la lógica de tus vistas.
¿Qué es la arquitectura base de una app MVVM en Swift?
La arquitectura parte de tres piezas que ya conoces y que son el esqueleto de cualquier app en Swift bien organizada.
- Una view que muestra la información al usuario.
- Un view model asociado que concentra la lógica de esa vista.
- Un model, que en este proyecto será únicamente el modelo record.
El view model es quien orquesta todo: recibe acciones de la vista, procesa datos y se comunica con las capas inferiores. Pero hay un problema: si conectas el view model directamente con una base de datos específica, quedas atado a esa tecnología para siempre.
¿Qué es un view model en MVVM? Es la capa intermedia que maneja la lógica de presentación. Recibe eventos de la vista, transforma datos del modelo y expone propiedades observables que la vista renderiza.
¿Cómo desacoplar el view model de la base de datos con un protocolo?
Aquí entra la pieza clave de toda esta planeación: el Database Service Protocol. En lugar de que tu view model hable con SwiftData o con Realm directamente, hablará con un protocolo.
Los protocolos en Swift obligan a quien los implemente a ejecutar las funciones que el protocolo define. Es un contrato. Tu view model no necesita saber qué base de datos hay detrás, solo que esa base de datos cumple con el contrato.
La idea es simple y poderosa: el view model recibe una instancia de cualquier clase que implemente Database Service Protocol, y a partir de ahí puede llamar a sus funciones sin preocuparse por la tecnología subyacente. Eso se llama inyección de dependencias, y es lo que te permite cambiar de motor de base de datos sin reescribir tu lógica.
¿Cómo se implementan SwiftData y Realm bajo el mismo protocolo?
Con el contrato definido, ahora puedes crear tantas implementaciones como quieras. En este proyecto verás dos.
SwiftData como servicio de base de datos
La primera implementación es SwiftData Database Service. Esta clase cumple con Database Service Protocol, así que está obligada a implementar todas sus funciones.
Pero hay un detalle: SwiftData maneja sus propias entidades, llamadas SD Records, que no son las mismas que las vistas esperan recibir. Para resolverlo aparece otro protocolo, To Record Protocol, que obliga a esos SD Records a convertirse en records genéricos que el view model entiende y puede pasar a la vista.
Realm como servicio de base de datos
La segunda implementación es Realm Database Service, que sigue exactamente la misma lógica. Implementa Database Service Protocol y trabaja con sus propios RD Records.
Esos RD Records también implementan To Record Protocol, lo que les permite traducirse al modelo record que la app sí reconoce y puede renderizar.
¿Para qué sirve To Record Protocol? Para forzar que las entidades específicas de cada base de datos, como SD Records o RD Records, se conviertan en un modelo común que las vistas puedan usar sin saber de dónde vienen.
¿Cuál es la ventaja real de inyectar el servicio de base de datos?
La magia ocurre al arrancar la aplicación. En ese momento eliges qué implementación inyectar en tus view models.
- Si inyectas SwiftData Service, tu app trabajará con SwiftData.
- Si inyectas Realm Service, trabajará con Realm.
- Si mañana aparece otra base de datos, creas una nueva implementación del protocolo y la inyectas.
El view model nunca cambia. La vista nunca cambia. Solo cambia la pieza que decides conectar al inicio. Y esto es justo lo que se traduce en código más limpio, escalable y mantenible en el tiempo, que es el objetivo de cualquier buena arquitectura.
¿Qué es la inyección de dependencias? Es pasarle a una clase las herramientas que necesita desde fuera, en lugar de que ella misma las cree. Así puedes intercambiar implementaciones sin modificar la clase que las usa.
En la próxima clase pasarás de este diagrama al código real, implementando paso a paso cada protocolo y cada servicio. ¿Qué base de datos crees que se sentirá más cómoda en tu proyecto, SwiftData o Realm? Cuéntame en los comentarios.