¿SwiftData necesita MVVM o es sobre-ingeniería? Hay un camino intermedio

⚖️ Añadir MVVM a esto puede ser sobre-ingeniería si peleas contra el framework. Pero existe un enfoque híbrido que respeta la arquitectura nativa y añade testabilidad solo donde importa.

🎯 SwiftData y SwiftUI están diseñados para trabajar juntos sin capas adicionales. Apple nos da @Query para lectura reactiva y @Environment(.modelContext) para escritura. Funciona perfecto.

💡 @Query ya es un ViewModel de lectura: observa la base de datos, actualiza automáticamente las vistas y gestiona el ciclo de vida de los datos. No necesitas replicar esto en otra capa.

✍️ La escritura es donde añadir abstracción tiene sentido: operaciones de negocio, validaciones, transformaciones de datos. Aquí un ViewModel propio mejora testeabilidad sin romper la reactividad.

🔄 Puedes mantener @Query en la vista para lectura y delegar las operaciones de escritura a un ViewModel que recibe el modelContext. Lo mejor de ambos mundos sin complejidad innecesaria.

🚫 No fuerces patrones tradicionales sobre frameworks modernos. SwiftUI y SwiftData ya tienen separación de responsabilidades: tus @Model son la capa de dominio, @Query gestiona el estado de lectura.

🛠️ Pregúntate: ¿necesito testear esto? Si la respuesta es no para la mayoría de tu app, usar SwiftData directamente en vistas es la decisión correcta. La simplicidad también es arquitectura.

👨‍💻 Respetar el framework no es renunciar a las buenas prácticas, es entender que las buenas prácticas evolucionan con las herramientas. ¿Tú en qué punto encuentras el equilibrio?