martes
jun262012
Encuesta sobre persistencia en Android
jtristanPoco a poco van surgiendo librerías que nos facilitan la vida a la hora de gestionar el acceso y manejo de la base de datos en Android. Por eso, nos gustaría saber qué ORMs utilizáis en vuestros proyectos. Además de votar, sería muy útil el que nos digáis qué os hizo decantaros por esa solución.
Desde ya, muchas gracias por vuestra colaboración.
Reader Comments (9)
PERSISTENCIA EN EL MÓVIL??¿?¿ estamos LOCOS?¿?¿, que pasa... la gente ha perdido el norte?¿?¿ la persistencia en sí misma es una ABERRACIÓN. Ale, menos hibernate y tonterías de esas y a estrujarse el coco los arquitectos y diseñadores en aprovechar la tecnología actual (JDBC) en hacer código OPTIMO.
P.D.: Es mejor currarse un CRUD con anotacionesy validadciones propias que se ajusten a las características del proyecto antes que currarte un CRUD con persistencia (hibernate u otras aberraciones) para replicar y duplicar el funcinoamiento de una BBDD en memoria.
No se que tiene de aberrante usar un ORM en un dispositivo movil. Cualquier app que tire de DB programada en lenguaje orientado a objetos es candidata a usar ORM, que no olvidemos que no es mas que Object-Relational-Mapping...
No se que parte de mi comentario no has entendido.... yo solo repudio el echo de replicar en memoria la BBDD. Yo no hablo de si es bueno o no utilizar un ORM, es más propongo que las empresas se curren su propio ORM para el acceso a BBDD.
@JOSe
Si que lo es, se supone que a pesar que podemos usar un patrón MVC en el móvil debemos tener en cuenta que los modelos no son persistentes y si es necesario cambiar un estado, debemos hacerlo a través de un servicio, porqué a como lo hagas directo alguien con un sniffer y credenciales expuestas.
En lo que si no comparto tu opinión es en lo de "currar tu propio ORM", vamos, que existen otros mucho más probados y que seguramente cubren tus necesidades, ¿cómo para qué reinventar la rueda? Aunque eso si, de preferencia usar algo como Spring Jdbc Template y SQL puro, si que simplifica (en mi opinión) más que usar Hibernate.
@xavs
Pues si, pero, ya poner un framework encima de la aplicación que sea la que se encargue de hacerlo, no lo sé, justamente en estos dispositivos en donde si que debemos pensar antes de usar cualquier librería y pensar en recursos limitados, porqué no todos los usuarios móviles cuentan con un Galaxy Nexus o un HTC One X. Aunque cueste un poco más picar código, procesar un json y pasarlo a un objeto, creo que es lo mejor para un dispositivo móvil.
@JOSe
Citando tu comentario de: "PERSISTENCIA EN EL MÓVIL??¿?¿ estamos LOCOS?¿?¿, que pasa... la gente ha perdido el norte?¿?¿"
Y luego..
"la persistencia en sí misma es una ABERRACIÓN"
seguido de:
"Ale, menos hibernate y tonterías de esas y a estrujarse el coco los arquitectos y diseñadores en aprovechar la tecnología actual (JDBC) en hacer código OPTIMO. "
Pues ya somos dos los que hemos entendido lo mismo.
Estoy con jose, repudio los orm que te venden espejitos de colores,
en un proycto de mediana/gran escala lo mejor es no depender de ninguna biblioteca del estilo hibernate, eclipse link, etc, lo mejor para proyectos grandes es crear tu propia abstraccion de la DB usando jdbc a lo macho.
Tampoco hay que pasarse con "a lo macho", que eso de que cada developer replique código no me gusta nada... pero que se pueden conjugar características varias para hacer algo bastante estable, mantenible, entendible y sobretodo... ajustado a las características del proyecto. En cuanto al tiempo de desarrollo, teniendo bien claras las ideas y conceptos, en una semana puedes tener algo muy guapo.
generación de código en greenDAO ... buff
Así por encima tiene mejor pinta ORMLite
reinventar la rueda nos haria retroceder en el tiempo.
Si alguien creo un ORM, usemoslos. Si son lentos para determinada aplicacion grande, se justifica hacer algo mas a mano. Lo cual no asegura que sea mejor ni mas rapido q un ORM.
Yo uso ORMs. es porq me simplifican la vida, y tengo cosas mas importantes en la vida (como pasar tiempo con mi familia o con mi novia) q romperme el coco haciendo algo q los suplante. y mis clientes mientras no se quejen de rendimiento... cual es el problema?