Ver la versión completa : Swift ¿Que ventajas tiene core data (iOS)?
Buenas,
Hace una semana que me puse a actualizarme con el tema iOS que llevaba desde el 4 sin tocarlo... asi que nada swift y vamos que nos vamos. Me encuentro trasteando con core data y no le veo la utilidad, asi que como estoy seguro que me pierdo algo voy a preguntar a los que haceis apps de ios a diario que ventaja tiene sobre usar sqlite a pelo.
A ver mis puntos son que sabiendo sql no veo que tiene core data que sea mejor, mas alla de comodidades y la "productividad" que no son importantes para mi.. es decir esto lo enfoco como programador, no como empresa que tiene que ser productiva....
Ventajas:
-diseñas la base de datos y las relaciones desde el propio xcode
-generas los nsmanaged objects y ya estas listo
-el codigo es simplon, fetch y push y vamos al tomate, no hay consultas sql.
Desventajas:
-las tipicas de cualquier framework, volvernos ********** al quitarnos de saber usar herramientas y cosas como SQL (Que fijate tu en android se usa y nadie ha muerto). Gracias a tanta abstraccion al final no sabemos ni hacer la O con un canuto..
Dejando de lado estas "ventajas", ¿que mas aporta core data que no veo?
Matizo mas para tratar de evitar debates innecesarios:
La pregunta no es si usar core data o no usarlo. NO es una cuestion de si una bbdd es util o no, ese punto no es relevante. Mi pregunta es, ¿que ventajas tiene usarlo frente a pasar de él y usar sqlite a pelo?.
La pregunta es, sabiendo sqlite, ¿vale la pena usar core data y dejar sqlite de lado?
Porque entiendo que alguien nuevo que hace una app por primera vez y no sabe sql le puede interesar aprender core data y se olvida de sql, para los que sabemos sql no vemos excesivas ventajas, de ahi mi pregunta. Sobre todo porque si luego haces apps de android tendras que tirar de sqlite.
¿Controles que se sincronicen con los datos sin escribir código?
Buen punto :), pero... todo eso despues de escribir todo el monton de codigo boilerplate para hacerlo funcionar, ¿no?
^MiSaTo^
24/11/2016, 12:48
Hombre tiene la ventaja de cualquier ORM también, que trabajas con objetos y es iOS quien te gestiona todo el tema de almacenaje, memoria y demás.
Dicho esto, depende de para qué quieras una bbdd yo creo que no he usado CoreData en años. Es más, de la tocho apli del banco quitamos la bbdd (que usabamos como caché) porque no nos daba ninguna ventaja. Ha sido la única aplicación en la que he necesitado una bbdd en todos estos años.
Por ejemplo estaba trabajando en una app de una inmobiliaria con 5000 propiedades, y para no estar constantemente haciendo consultas se copiaba la bd a local en el primer arranque y luego todo era obviamente "rapidisimo" al ser consultas locales, se usaba sqlite a pelo sin mas historias.
Ahora claro te dicen de modernizar la app y usar core data y no veo una cantidad de cosas interesantes como para actualizarse. Lo veo como decir, "vamos a cambiar esta app que funciona perfectamente de obj-c a swift" , ¿por qué?, pues porque mola mas swift xDD
Que ojo, no le quito su merito al core data, se trabaja con objetos y tal, pero vaya teniendo tu "workflow" ya montado y tus wrapers (¿te acuerdas del tuyo misato?) con una bd y sabiendo sql, readaptarse no veo que me aporte una gran cantidad de cosas.
Supongo tambien que no he trabajado en una app enterprise como para poder valorar correctamente su uso, y claro en apps de andar por casa pues ni fu ni fa. Pero claro oyes a todos hablar maravillas del data....
^MiSaTo^
24/11/2016, 13:44
Con 5000 registros si es solo una tabla yo los dejaba en memoria que te será mucho más rápido. O guardaba el json.
Pero montar coredata solo para eso me parece overkill. Es más no merece la pena ni SQLite xDD
EDIT: Pensándolo mejor depende de las búsquedas que hagas si puede ser más eficiente tenerlo en una bbdd que serializado o en memoria.
Parece que solo quieren actualizar para decir que usamos tal tecnologia, por postureo.
Parece que solo quieren actualizar para decir que usamos tal tecnologia, por postureo.
Lo tipico, ahora esta de moda swift pues lo usamos, y el core data ese pues tambien lo quiero en mi app, y oye que hay gps pues pongame 2 de gps en mi app aunque no lo use xD
Con 5000 registros si es solo una tabla yo los dejaba en memoria que te será mucho más rápido. O guardaba el json.
Pero montar coredata solo para eso me parece overkill. Es más no merece la pena ni SQLite xDD
EDIT: Pensándolo mejor depende de las búsquedas que hagas si puede ser más eficiente tenerlo en una bbdd que serializado o en memoria.
Era una tabla si, y las busquedas son lo tipico, que si filtra por la urbanizacion, que si filtra por precio, que si por num de habitaciones, etc, etc. Vamos todas las combinaciones posibles de parametros...
La idea de tenerlas en la bd local es ahorrar el ancho de banda por cada vez q un usuario consulta la lista, y en una app asi le puedes dar mucho tute mirando casas, de ahi que se bajaran en el inicio cuando instalas la app y luego a tirar millas con el local. No es que sea la panacea pero tenia su uso la bbdd.
Con 5000 registros si es solo una tabla yo los dejaba en memoria que te será mucho más rápido. O guardaba el json.
Pero montar coredata solo para eso me parece overkill. Es más no merece la pena ni SQLite xDD¿Puedes por favor venir y explicárselo a toda nuestra comunidad? se llevan una empalmada con ORMs y Realm.io que no pueden ni caerse de morros. Y luego pa' na, porque por cuatro datos que tiras de un json cacheado con etags no merece hacer una query o un index. Hasta monté un wrapper para un key-value store en binario, rapidísimo, y no eran capaces de ver las ventajas.
^MiSaTo^
25/11/2016, 08:50
Lo tipico, ahora esta de moda swift pues lo usamos, y el core data ese pues tambien lo quiero en mi app, y oye que hay gps pues pongame 2 de gps en mi app aunque no lo use xD
Era una tabla si, y las busquedas son lo tipico, que si filtra por la urbanizacion, que si filtra por precio, que si por num de habitaciones, etc, etc. Vamos todas las combinaciones posibles de parametros...
La idea de tenerlas en la bd local es ahorrar el ancho de banda por cada vez q un usuario consulta la lista, y en una app asi le puedes dar mucho tute mirando casas, de ahi que se bajaran en el inicio cuando instalas la app y luego a tirar millas con el local. No es que sea la panacea pero tenia su uso la bbdd.
Hombre es evidente que quieres cachear la consulta de alguna manera. Lo que me refiero es que a lo mejor para esa cache no te hace falta tener una base de datos y puedes hacerlo de otra manera más eficiente.
Es algo que se hace en el 99% de apps xD
^MiSaTo^
25/11/2016, 08:53
¿Puedes por favor venir y explicárselo a toda nuestra comunidad? se llevan una empalmada con ORMs y Realm.io que no pueden ni caerse de morros. Y luego pa' na, porque por cuatro datos que tiras de un json cacheado con etags no merece hacer una query o un index. Hasta monté un wrapper para un key-value store en binario, rapidísimo, y no eran capaces de ver las ventajas.
Es que depende de la cantidad de datos, las relaciones que haya entre ellos (si son más de una tabla o no) y las búsquedas que se hagan.
Pero vamos yo llevo 7 años haciendo apps y muy pocas veces he tenido la necesidad de usar una base de datos.
El caso más común es lo que ha dicho Eskema, una sola tabla y no muchos registros. Para eso no merece la pena montar la bbdd a no ser que hagas búsquedas complejas.
Ahora bien, también digo que CoreData es bastante más eficiente que SQLite a pelo.
Hombre es evidente que quieres cachear la consulta de alguna manera. Lo que me refiero es que a lo mejor para esa cache no te hace falta tener una base de datos y puedes hacerlo de otra manera más eficiente.
Es algo que se hace en el 99% de apps xD
Lo se, pero aqui entramos en el "vamos a poner una bbdd porque es lo que hay en el server", asi que la bbdd local no es mas que un clon de la web... ya se sabe "le ponemos lo mismo al cliente no se vaya a quejar" xD
Como dices tu me podria bajar los 5k registros al abrir la app por primera vez, serializarlos luego a un json y tenerlos ahi guardados para luego leer el json en cada arranque de la app y tirar de memoria, peeeero la tecnologia manda xDDD
Si tu pregunta es sobre si usar o no coredata (o por extension cualquier ORM) pues... depende.
Alguien muy serio y muy teórico te dirá que todos los ORM parten de un error de base, y es confundir una estructura de datos (las tablas) con un objeto. Ambos no son, ni pueden ser lo mismo, y por eso, casi siempre derivan en problemas gravísimos de rendimiento.
Ahora bien, si vas a hacer operaciones CRUD simples y es importante almacenar datos puede ser una buena opción.
Pero de todo esto: ¿cual es la respuesta correcta cuando empiezas un nuevo proyecto? La respuesta correcta y la que debes tomar siempre, es que no debes decidir qué sistema de base de datos vas a necesitar ni al principio ni a la mitad del proyecto. Has de posponer todo lo posible, hasta el último día la decision sobre la base de datos que vas a usar. Mientras tanto, usa mocks y si es necesario, la implementación más simple que se te ocurra. En un momento dado verás que incluso esa implementación temporal y en apariencia incompleta puede ser la correcta.
Si tu pregunta es sobre si usar o no coredata (o por extension cualquier ORM) pues... depende.
Alguien muy serio y muy teórico te dirá que todos los ORM parten de un error de base, y es confundir una estructura de datos (las tablas) con un objeto. Ambos no son, ni pueden ser lo mismo, y por eso, casi siempre derivan en problemas gravísimos de rendimiento.
Ahora bien, si vas a hacer operaciones CRUD simples y es importante almacenar datos puede ser una buena opción.
Pero de todo esto: ¿cual es la respuesta correcta cuando empiezas un nuevo proyecto? La respuesta correcta y la que debes tomar siempre, es que no debes decidir qué sistema de base de datos vas a necesitar ni al principio ni a la mitad del proyecto. Has de posponer todo lo posible, hasta el último día la decision sobre la base de datos que vas a usar. Mientras tanto, usa mocks y si es necesario, la implementación más simple que se te ocurra. En un momento dado verás que incluso esa implementación temporal y en apariencia incompleta puede ser la correcta.
La pregunta no es si usar core data o no usarlo. NO es una cuestion de si una bbdd es util o no, ese punto me la pela muy mucho xD. Mi pregunta es que ventajas tiene usarlo frente a pasar de él y usar sqlite a pelo.
La pregunta es, sabiendo sqlite, ¿vale la pena usar core data y dejar sqlite de lado?
Porque entiendo que alguien nuevo que hace una app por primera vez y no sabe sql le puede interesar aprender core data y se olvida de sql, para los que sabemos sql no vemos excesivas ventajas, de ahi mi pregunta. Sobre todo porque si luego haces apps de android tendras que tirar de sqlite.
A eso me refiero Eskema, es que al ppio no deberias tomar esa decision, la mejor opcion es no usar ninguno!!
^MiSaTo^
28/11/2016, 12:42
Tu pregunta es basicamente qué ventaja tiene usar un ORM frente a SQL a pelo. No simplemente si usar CoreData o no.
Las ventajas de usar un ORM son varias pero principalmente abstracción y encapsulación. Puedes buscar por internet las ventajas y desventajas de usar un ORM frente a usar SQL directamente que hay como mil artículos del tema.
Sobre Core Data en concreto también hay mucho, a mi me gustan mucho los artículos de Cocoa with Love (https://www.cocoawithlove.com/2010/02/differences-between-core-data-and.html) (ojo que es un artículo bastante antiguo, de hecho lo menciona en la cabecera, pero oye igual sirve como referencia).
Como siempre lee mucho, entérate de qué es cada cosa y cómo funciona, y ya valoras tú si merece la pena para tu proyecto o no. Precisamente este es el trabajo de un ingeniero de software ;)
-----Actualizado-----
A eso me refiero Eskema, es que al ppio no deberias tomar esa decision, la mejor opcion es no usar ninguno!!
No entiendo en qué basas esto amkam o a qué te refieres exactamente, a no usar ninguna base de datos? no usar un ORM?
Ya pero dado que es iOS no creo, o no conozco otro ORM que no sea core data, de ahi que la pregunta vaya a mas ese tema.
El caso es que partimos de la base de que vamos a usar una bbdd si o si (no entramos a valorar si es una chorrada o no, el cliente manda), por lo tanto la cosa es "obvia", ¿tiramos por lo super cool que es core data, o nos arreglamos a pelo con sqlite porque el tema "objetos" de core data nos la trae al pairo?, y mas que tirar debo hablar en singular pq son el currito y estoy solo xD
Porque entiendo que en una app enterprise tocha usar core data puede mejorar la visibilidad del codigo y tenerlo todo mas "organizado", mientras que una app mas sencilla lo mismo no necesitamos tantos objetos ni tanta "maric0nada" de core data xD
Todo esto viene por lo tipico, hablas con algunos y lo primero que te sueltan es "eres gilip0llas si no usas core data, sql es el pasado men!!", otros que pasan de core data como de comer mierda porque "es una chorrada y con sql nos sobra", ya ya, tipico de este curro, que cada uno piensa una cosa y como core data es nuevo para mi pues pregunto por opiniones.
Esto (como ejemplo) se parece un poco a "¿uso maps o tiro de google maps y añado librerias a mi proyecto?", dado que estas en iOS lo logico es usar lo que te ofrece apple y olvidarte de nada "externo"... algo asi veo con core data vs sqlite, en el sentido de que usas lo recomendado o tiras por otro lado.
^MiSaTo^
28/11/2016, 13:05
Hay otros ORM aparte de CoreData y CoreData no es el recomendado, de hecho la propia Apple te dice lo mismo que te he dicho yo, que depende del proyecto que tengas xD
De todos modos con una actitud de "me la pela usar esto porque yo se SQL" pues tampoco vamos a ninguna parte.
Aparte, ya has dicho que el cliente quiere CodeData pues o le convences para seguir usando SQLite a pelo o te toca refactorizar ;)
Hay otros ORM aparte de CoreData y CoreData no es el recomendado, de hecho la propia Apple te dice lo mismo que te he dicho yo, que depende del proyecto que tengas xD
De todos modos con una actitud de "me la pela usar esto porque yo se SQL" pues tampoco vamos a ninguna parte.
Aparte, ya has dicho que el cliente quiere CodeData pues o le convences para seguir usando SQLite a pelo o te toca refactorizar ;)
El cliente solo ha pedido una bbdd, no ha especificado y el jefe me ha dicho lo tipico, "ponemos core data y asi molamos mas pq usamos las cosas de apple..."
Asi que dado el tema estoy de research viendo que ofrece core data respecto a tirar de sqlite.... no es una actitud de me la pela, si no mas bien que estoy evaluando las comodidades y viendo el consenso de la gente que ya lo ha usado, como dices se trata de evaluar una tecnologia/framework, y como seguro que me pierdo detalles que no estan en los pros/cons del primer post pues pregunto...
No entiendo en qué basas esto amkam o a qué te refieres exactamente, a no usar ninguna base de datos? no usar un ORM?
Porque tomar una decisión pronto sobre qué base de datos usar centra el desarrollo en ésta. Empiezas a crear entidades que, directamente, se apoyan sobre una base de datos SQL, y en concreto seguramente ya hayas decidido cual, sqlite, coredata, mysql, oracle, etc. Pasas los días, terminas los sprints y te das cuenta que sqlite no cumple con lo que necesitabas, que haber elegido sqlite hace aguas por que tu (por ejemplo) aplicacion permite concurrencia pero SQLite no: y que a lo mejor, un simple mapa clave-valor en memoria hubiera sido suficiente, o un fichero, o una base de datos nosql, o una simple cache. Has creado una dependencia innecesaria.
Has tomado una decisión cuando aún no estabas seguro que debías de tomarla. Se va un poco de varas de este asunto, pero Uncle Bob ya habló de esto mismo hace tiempo, echadle un ojo si teneis tiempo: https://8thlight.com/blog/uncle-bob/2012/05/15/NODB.html
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.