¿Tiene sentido usar ORM en el desarrollo de Android?

¿Tiene sentido usar un ORM en el desarrollo de Android o el marco está optimizado para un acoplamiento más estrecho entre la interfaz de usuario y la capa de base de datos?

Antecedentes : Acabo de comenzar con el desarrollo de Android, y mi primer instinto (proveniente de un fondo .net) fue buscar un pequeño mapeador relacional de objetos y otras herramientas que ayuden a reducir el clode repetitivo (por ejemplo, POJOs + OrmLite + Lombok ).

Sin embargo, mientras que el desarrollo de mi primera aplicación juguete me topé con una clase de interfaz de usuario que requiere explícitamente un cursor de base de datos: AlphabetIndexer. Eso me hizo preguntarme si tal vez la biblioteca de Android no es adecuada para un desacoplamiento estricto de la capa de UI y DB y si voy a perder muchas funciones útiles y que ahorran tiempo si trato de usar POJO en todas partes (en lugar de acceso directo a la base de datos) )

Aclaración : Soy bastante consciente de las ventajas de usar ORM en general , estoy específicamente interesado en qué tan bien funciona la biblioteca de clases de Android.

Android no funciona tan bien con otros marcos como podría. Su estilo de desarrollo recomendado asume que construye todo desde su API, sin otras bibliotecas. La capa de IU está muy unida al modelo. Este estilo es ideal para escribir aplicaciones modulares más pequeñas, no para aplicaciones complejas.

Debe reflexionar sobre si desea tener alguna de las funciones de Android; si no lo necesita, no tiene nada que perder al usar un ORM. Si este no es el caso, es posible que deba conformarse con un híbrido. Use un ORM para todo lo que pueda, pero enganche ganchos a Cursorcualquier otro objeto de bajo nivel que necesite. Si el ORM que elige requiere DAO (no estoy familiarizado con el que mencionó), entonces esta capa es probablemente el mejor lugar para ellos.

Alternativamente, es posible que no necesite utilizar ningún ORM externo. Si sus necesidades son sencillas, puede escribir una capa de acceso a datos simple que las satisfaga. La mayoría de los requisitos de la base de datos de aplicaciones no son excelentes. Si solo tiene un par de tablas, simplemente escriba un par de clases de acceso y los objetos modelo y llámelo bueno.

YAGNI y KISS son las palabras clave para el éxito aquí. Te sugiero que pases unos días haciendo prototipos. No tengas miedo de tirar las aplicaciones de prueba simples. Pruebe todas sus ideas solo, luego decida si alguna o todas funcionarán para su proyecto.

Depende de lo que hagas con tu modelo de datos. Si tiene un código existente que manipula un modelo orientado a objetos, y si desea conservar esos objetos en una base de datos sqlite, necesita una orm.

Si está escribiendo un nuevo código de Android desde cero, evitaría un modelo de datos en memoria a menos que la aplicación realice manipulaciones OO realmente complejas, como podría hacer un programa CAD, por ejemplo. Pero, para la mayoría de los programas, mantenga el modelo de datos en la base de datos y deje que la cadena de objetos Cursor, Adapter y View haga un gran esfuerzo por usted.