Ha senso usare ORM nello sviluppo Android?

Ha senso utilizzare un ORM nello sviluppo Android o il framework è ottimizzato per un accoppiamento più stretto tra l'interfaccia utente e il livello DB?

Background : ho appena iniziato con lo sviluppo di Android, e il mio primo istinto (proveniente da uno sfondo .net) è stato quello di cercare un piccolo mappatore relazionale agli oggetti e altri strumenti che aiutino a ridurre il clode della caldaia (ad esempio POJOs + OrmLite + Lombok ).

Tuttavia, mentre in via di sviluppo la mia prima applicazione giocattolo sono incappato in una classe di interfaccia utente che richiede esplicitamente un cursore del database: AlphabetIndexer. Ciò mi ha fatto chiedermi se forse la libreria Android non è adatta per un rigoroso disaccoppiamento dell'interfaccia utente e del livello DB e che mi perderò molte funzioni utili e che risparmieranno tempo se provo ad usare POJO ovunque (invece dell'accesso diretto al database ).

Chiarimento : sono abbastanza consapevole dei vantaggi dell'utilizzo di ORM in generale , sono particolarmente interessato al modo in cui la libreria di classi Android gioca con essa.

Android non funziona così bene con altri framework come potrebbe. Lo stile di sviluppo consigliato presuppone che tu costruisca tutto dalla sua API, senza altre librerie. Il livello dell'interfaccia utente è strettamente associato al modello. Questo stile è ideale per scrivere app modulari più piccole, non per applicazioni complesse.

È necessario riflettere sul fatto se si desidera una delle funzionalità di Android; se non ti serve, non hai nulla da perdere usando un ORM. In caso contrario, potrebbe essere necessario accontentarsi di un ibrido. Usa un ORM per tutto ciò che puoi, ma concediti un gancio per se Cursore qualsiasi altro oggetto di basso livello di cui hai bisogno. Se l'ORM scelto richiede DAO (non ho familiarità con quello che hai citato), allora questo livello è probabilmente il posto migliore per loro.

In alternativa, potrebbe non essere necessario utilizzare alcun ORM esterno. Se le tue esigenze sono chiare, puoi scrivere un semplice livello di accesso ai dati che li soddisfi. La maggior parte dei requisiti del database delle app non è eccezionale. Se hai solo un paio di tabelle, scrivi solo un paio di classi di accesso e gli oggetti del modello e chiamalo buono.

YAGNI e KISS sono le parole chiave per il successo qui. Ti suggerisco di dedicare qualche giorno alla prototipazione. Non abbiate paura di buttare via le semplici app di prova. Prova tutte le tue idee da solo, quindi decidi se alcune o tutte funzioneranno per il tuo progetto.

Dipende da cosa fai con il tuo modello di dati. Se si dispone di codice esistente che manipola un modello orientato agli oggetti e se si desidera mantenere tali oggetti in un database sqlite, è necessario un orm.

Se stai scrivendo un nuovo codice Android da zero, eviterei un modello di dati in memoria a meno che l'app non esegua manipolazioni OO davvero complesse, come potrebbe ad esempio un programma CAD. Ma, per la maggior parte dei programmi, mantieni il modello di dati nel database e lascia che la catena di oggetti Cursor, Adapter e View faccia un lavoro pesante per te.