¿Tiene una idea para una aplicación pero no tiene los conocimientos de programación para comenzar a construirla? En esta serie de blogs semanales, Cómo dar rienda suelta a su desarrollador de aplicaciones interno, lo llevaré a usted, el no programador, paso a paso a través del proceso de creación de aplicaciones para iPhone, iPod touch y iPad. Únase a mí cada semana en esta aventura y experimentará lo divertido que puede ser convertir sus ideas en realidad. Esta es la Parte 14 de la serie. Si recién está comenzando ahora, consulte el comienzo de la serie aquí. (Esta publicación se ha actualizado a Swift 1.2, iOS 8 y Xcode 6.3)
Core Data es la tecnología que le permite almacenar y recuperar información en un dispositivo iOS. Aunque es una tecnología avanzada a menudo difícil de comprender, mi objetivo en esta publicación es simplificar los datos básicos para que los principiantes puedan usarla fácilmente.
Empezaré por darles una idea general de cómo funciona Cora Data. Luego, veremos la implementación predeterminada de Apple de Core Data, y luego le mostraré cómo podemos mejorarla fácilmente.
Índice de contenido
- 1
- 2 Entidades y datos principales
- 3 Creando Entidades
- 4 Modelado de entidades con un modelo de datos de entidad
- 5 Generación de clases de entidad a partir de un modelo de datos de entidad
- 6 Crear objetos de entidad
- 7 Guardar objetos de entidad en una base de datos
- 8 Trabajar con el contexto del objeto
- 9 Datos básicos listos para usar
- 10 Modelo de datos centrales mejorado
Entidades y datos principales
Como mencioné en mi publicación anterior, los datos de su aplicación generalmente toman la forma de entidades, que son las Modelo en el patrón de diseño Modelo-Vista-Controlador. Una entidad representa un objeto en el mundo real y tiene atributos que modelan un objeto del mundo real. Por ejemplo, el objetivo principal del iAppsReview que hemos estado creando es para brindar a los usuarios un lugar para escribir reseñas de aplicaciones. Al modelar entidades para esta aplicación, puede crear un ReviewEntity que describe una revisión del mundo real. Puede crear un AppCategoryEntity que describe las diferentes categorías que puede asignar a una aplicación, e incluso puede crear una UserEntity para describir a la persona que usa su aplicación.
Creando Entidades
Entonces, ¿cómo se crean entidades para sus aplicaciones? Hay tres pasos principales:
- Modele o defina las entidades en un modelo de datos de la entidad;
- Utilice Xcode para generar una clase de entidad a partir de cada entidad en el modelo de datos;
- Agregue código a su aplicación que crea objetos de entidad a partir de las clases de entidad y los manipula.
Descubramos más sobre cada uno de estos pasos.
Modelado de entidades con un modelo de datos de entidad
Xcode proporciona una herramienta visual llamada modelo de datos de entidad (o simplemente “modelo de datos” para abreviar) que puede utilizar para modelar las entidades de su aplicación. Por ejemplo, consulte el ReviewEntity que se muestra en el lado izquierdo del modelo de datos de la entidad que se muestra en Figura 1.
![]() |
Figura 1 – Modelo de datos de una entidad |
Esta entidad tiene atributos como nombre de la aplicación, comentarios, imagen, clasificación, categoría y crítico. Como puede ver, también hay un AppCategoryEntity y un UserEntity que poseen sus propios atributos y cada uno tiene una relación con el ReviewEntity.
Generación de clases de entidad a partir de un modelo de datos de entidad
Las entidades que define en un modelo de datos de entidad no son clases Swift. Son simplemente una representación de sus entidades que están definidas en un diagrama. Sin embargo, realmente necesita clases de entidad en su aplicación, por lo que después de definir las entidades en el modelo de datos de la entidad, su siguiente paso es crear una clase Swift a partir de cada entidad en el modelo como se muestra en Figura 2.
![]() |
Figura 2: debe generar clases de entidad a partir de las entidades en el modelo de datos. |
Afortunadamente, Xcode puede hacer esto por usted en un solo paso, como verá.
Crear objetos de entidad
Una vez que haya generado clases a partir de sus entidades, puede agregar código a su aplicación que crea objetos a partir de estas clases de entidad y las manipula.
Por ejemplo, como se muestra en figura 3, en respuesta a un usuario que escribe una reseña, puede crear una nueva ReviewEntity objeto y almacene la categoría, la calificación, el nombre de la aplicación, los comentarios y la imagen en las propiedades del objeto.
![]() |
Figura 3: puede guardar los valores de control de la interfaz de usuario en las propiedades de un objeto de entidad. |
Guardar objetos de entidad en una base de datos
Después de crear un objeto de entidad y almacenar información en sus diversas propiedades, ¿cómo guarda la entidad para que la próxima vez que abra la aplicación pueda ver la revisión nuevamente? Aquí es donde Core Data viene al rescate.
Core Data guarda sus entidades en un base de datos. La mayoría de los que no son programadores están familiarizados con el término “base de datos” y, al menos, tienen la vaga noción de que es un lugar donde se almacenan sus datos y desde donde se pueden recuperar en una fecha posterior. Profundicemos y descubramos más sobre la estructura de una base de datos.
Detrás de escena, Core Data crea una base de datos para su aplicación y luego agrega una mesa en la base de datos para cada una de las entidades de la aplicación como se muestra en Figura 4. Note que Core Data crea una tabla con el mismo nombre que su entidad pero con un prefijo “Z”.
![]() |
Figura 4: Core Data almacena sus entidades en una base de datos. |
Una tabla puede contener varios registros de datos del mismo tipo. Por ejemplo, todas sus opiniones se almacenan en el ZREVIEWENTITY tabla, todas las categorías de aplicaciones se almacenan en la ZAPPCATEGORYENTITY tabla, y la información del usuario se almacena en el ZUSERENTIDAD mesa.
Core Data crea una columna en la tabla para cada propiedad de la entidad asociada. Por ejemplo, como se muestra en Figura 5, la ZAPPCATEGORYENTITY la tabla tiene dos columnas, categoria ID y nombre, uno para cada atributo en AppCategoryEntity.
![]() |
Figura 5: Core Data crea una columna de tabla para cada propiedad de la entidad. |
En Figura 5, hay tres registros en la tabla, también conocidos como filas. Cada vez que guardas una nueva AppCategoryEntity objeto, se agrega un nuevo registro al ZAPPCATEGORYENTITY mesa.
La magia que realiza Core Data al convertir sus entidades en filas de datos en una tabla de datos se conoce como mapeo relacional de objetos (ORM). Se llama así porque Core Data convierte los objetos de su entidad en datos almacenados en un base de datos relacional (llamado así porque las tablas de una base de datos pueden tener relaciones entre ellas). El uso de Core Data le ahorra la carga de aprender las complejidades de la programación de bases de datos. ¡Puede guardar, recuperar, actualizar y eliminar entidades sin aprender un lenguaje de programación de bases de datos!
La base de datos que Apple ha elegido utilizar en dispositivos iOS es SQLite. La base de datos SQLite es compacta y es una de las bases de datos más implementadas en el mundo, utilizada en otros sistemas populares como Android de Google, Windows Phone 8 de Microsoft, Blackberry de RIM y Maemo de Nokia. Para obtener más información sobre SQLite, consulte este enlace.
Trabajar con el contexto del objeto
Core Data se compone de un conjunto de clases en Cocoa Touch Framework. La clase de datos básicos principal con la que trabajará es NSManagedObjectContext. Envía mensajes a una instancia del contexto del objeto para crear, recuperar, insertar, actualizar y eliminar las entidades de su aplicación. El contexto del objeto realiza un seguimiento de todas las entidades que ha recuperado o creado, así como de los cambios que ha realizado en las entidades.
El contexto del objeto ofrece un enfoque de todo o nada para actualizar sus entidades. Cuando le envías un saveEntities mensaje, guarda todas las entidades que han cambiado. No ofrece la opción de guardar cambios en una o más entidades seleccionadas.
Detrás de escena, el contexto del objeto utiliza un coordinador de tienda persistente objeto (una instancia del NSPersistentCoordinater class), que utiliza para comunicarse con la base de datos SQLite. El coordinador de la tienda persistente conoce el nombre y la ubicación de la base de datos. Utiliza un modelo de objetos gestionados (una instancia de NSManagedObjectModel) que conoce todas las entidades del modelo de datos y sus relaciones.
Datos básicos listos para usar
La arquitectura de Core Data lista para usar deja mucho que desear. Para mostrarte lo que quiero decir Figura 6 proporciona una descripción general de la arquitectura predeterminada que obtiene cuando crea un nuevo proyecto en Xcode y selecciona el Usar datos básicos opción.
![]() |
Figura 6 – La arquitectura de datos central lista para usar |
Como puede ver, el AppDelegate El objeto almacena una referencia a un Contexto de objeto gestionado. El contexto del objeto usa un Coordinador de tienda persistente, que a su vez utiliza un Modelo de objetos gestionados para recuperar y actualizar entidades de la base de datos SQLite.
En esta arquitectura predeterminada, un contexto de objeto único adjunto al AppDelegate es referenciada por todos los controladores de vista en su aplicación. A medida que se crea cada controlador de vista, una referencia al AppDelegateEl contexto del objeto se pasa al controlador, que luego almacena en su propio managedObjectContext propiedad. Apple recomienda que coloque un código en sus controladores de vista que envíe mensajes al contexto del objeto para crear, recuperar, actualizar y eliminar entidades.
El problema con este enfoque es que rompe la regla de separar tu aplicación en estas distintas secciones:
- Interfaz de usuario
- Lógica central
- Datos
La forma más formal de separar secciones es en Modelo, Vista y Controlador.
Como aprendiste en mi publicación anterior, el controlador de vista es parte de la interfaz de usuario. El único código que pertenece al controlador de vista es el código que tiene algo que ver con la interfaz de usuario. Por lo tanto, el código que se utiliza para recuperar, manipular y actualizar entidades no no pertenecen al controlador de vista.
Esto no es solo un pensamiento de torre de marfil. Poner el código de manipulación de su entidad en la interfaz de usuario tiene implicaciones prácticas que pueden dificultar la ampliación de su aplicación en el futuro. Por ejemplo, si mejora su aplicación en una fecha posterior para guardar y recuperar entidades de la web, tendrá que encontrar todos los lugares que usan esta lógica de datos básicos y cambiarlos. Como otro ejemplo, si crea una aplicación Apple Watch, debe mover su lógica de datos básicos a un proyecto de marco separado al que se puede acceder desde la aplicación WatchKit, así como desde la aplicación iPhone asociada.
Lo que necesita es un lugar para colocar este código que lo encapsule u oculte de la interfaz de usuario.
Modelo de datos centrales mejorado
Entonces, ¿dónde debería poner el código de manipulación de su entidad? ¡Debería ponerlo en una clase de controlador comercial!
Figura 7 muestra un modelo de Core Data mejorado donde el Contexto de objeto gestionado se adjunta a un Regulador de negocios, y el código para recuperar y guardar entidades se almacena en los métodos de la Regulador de negocios.
![]() |
Figura 7: una arquitectura de datos central mejorada |
¿Cuáles son los beneficios de este enfoque?
En primer lugar, encapsula el código de manipulación de la entidad dentro del controlador comercial. Ahora puede pasar mensajes desde el controlador de vista al controlador de negocios para recuperar y actualizar entidades, y la mecánica de cómo se recuperan y actualizan esas entidades están ocultas en la interfaz de usuario. Esto significa que puede cambiar dónde y cómo se almacenan las entidades en una fecha posterior sin afectar la interfaz de usuario.
Otro beneficio de este modelo es la reutilización. Cuando coloca el código de recuperación, manipulación y actualización de su entidad en los métodos de un controlador comercial, puede llamar a esos mismos métodos desde múltiples controladores de vista e incluso desde múltiples aplicaciones. Esto es lo que llamamos reutilización!
Hay otro beneficio de esta arquitectura que puede no ser evidente. Como mencioné anteriormente, un contexto de objeto es una proposición de todo o nada. Cuando le pide que guarde los cambios, guarda los cambios en todas las entidades de su aplicación. Permitir que cada controlador comercial tenga su propio contexto de objeto permite un control más preciso sobre cuándo y cómo se guardan las entidades en la base de datos. Puedes tener un Cliente controlador comercial y un Orden controlador comercial, cada uno con su propio contexto de objeto. Esto le permite recuperar y actualizar CustomerEntity objetos sin afectar OrderEntity objetos.
Sin embargo, hay ocasiones en las que desea o necesita que varios controladores comerciales compartan el mismo contexto de objeto. Como verá en una publicación futura, esta arquitectura también le permite hacer precisamente eso.
Conclusión
Cubrimos mucho terreno conceptual en esta publicación. Ha aprendido sobre modelos de datos de entidades, bases de datos con sus tablas, columnas, filas y cómo Core Data maneja gran parte del trabajo pesado de manipular entidades por usted. En la publicación de la próxima semana, aplicaremos lo que ha aprendido esta semana y agregaremos Core Data al iAppsReview proyecto.
<< Anterior Siguiente >>