Faz sentido usar o ORM no desenvolvimento do Android?

Faz sentido usar um ORM no desenvolvimento do Android ou a estrutura é otimizada para um acoplamento mais rígido entre a interface do usuário e a camada do banco de dados?

Antecedentes : Comecei o desenvolvimento do Android e meu primeiro instinto (proveniente de um plano .net) foi procurar um pequeno mapeador objeto-relacional e outras ferramentas que ajudassem a reduzir o clode de clichê (por exemplo, POJOs + OrmLite + Lombok ).

No entanto, ao desenvolver minha primeira aplicação brinquedo me deparei com uma classe UI que exige explicitamente um cursor de banco de dados: AlphabetIndexer. Isso me fez pensar se talvez a biblioteca do Android não seja adequada para uma dissociação rigorosa da camada de interface do usuário e do banco de dados e que eu vou perder muitos recursos úteis e que economizam tempo se tentar usar POJOs em todos os lugares (em vez de acesso direto ao banco de dados )

Esclarecimento : Estou bastante ciente das vantagens de usar o ORM em geral , estou especificamente interessado em saber como a biblioteca de classes do Android funciona com ele.

O Android não funciona tão bem com outras estruturas quanto poderia. Seu estilo de desenvolvimento recomendado pressupõe que você construa tudo a partir de sua API, sem outras bibliotecas. A camada da interface do usuário está fortemente acoplada ao modelo. Esse estilo é ideal para escrever aplicativos modulares menores, não para aplicativos complexos.

Você precisa pensar um pouco sobre se deseja ou não alguma funcionalidade do Android; se você não precisar, não terá nada a perder usando um ORM. Se não for esse o caso, pode ser necessário optar por um híbrido. Use um ORM para tudo o que puder, mas dedique-se a se Cursore a outros objetos de baixo nível que você precisar. Se o ORM que você escolher exigir DAOs (não estou familiarizado com o que você mencionou), essa camada provavelmente será o melhor lugar para eles.

Como alternativa, pode ser necessário não usar nenhum ORM externo. Se suas necessidades são diretas, você pode escrever uma camada simples de acesso a dados que atenda a elas. A maioria dos requisitos de banco de dados de aplicativos não é ótima. Se você tiver apenas algumas tabelas, basta escrever algumas classes de acesso e os objetos de modelo e chamar de bom.

YAGNI e KISS são as palavras-chave para o sucesso aqui. Eu sugiro que você gaste alguns dias fazendo protótipos. Não tenha medo de jogar fora os aplicativos de teste simples. Experimente todas as suas idéias sozinho e decida se alguma ou todas funcionarão para o seu projeto.

Depende do que você faz com seu modelo de dados. Se você possui um código existente que manipula um modelo orientado a objetos e se deseja persistir esses objetos em um banco de dados sqlite, precisa de um orm.

Se você estiver escrevendo um novo código Android do zero, evitaria um modelo de dados na memória, a menos que o aplicativo execute manipulações OO realmente complexas, como um programa CAD, por exemplo. Mas, para a maioria dos programas, mantenha o modelo de dados no banco de dados e deixe a cadeia de objetos Cursor, Adapter e View fazer muito trabalho pesado para você.