come decidere tra accesso diretto al database e fornitore di contenuti?

Sto scrivendo un’applicazione che si compone di logica aziendale e parti dell’interfaccia utente. C’è una grande quantità di dati da memorizzare e accedere / modificare sia da BL che dall’interfaccia utente. Nella maggior parte dei casi le modifiche ai dati memorizzati dovrebbero essere immediatamente riflesse dall’interfaccia utente.

Come posso decidere se utilizzare o meno l’accesso diretto al DB? fornitore di contenuti?

Ho fatto qualche lettura sull’argomento ( 1 , 2 ) e capisco la differenza tra queste due opzioni.

Condividi le tue opinioni su altri aspetti del problema, come le prestazioni, il livello di difficoltà di sviluppo del codice e la manutenibilità, ecc.

Nelle app che ho scritto, ho scoperto che una volta superata la curva di apprendimento, l’implementazione di ContentProvider è piuttosto semplice.

Pro :

  • Nessuna dipendenza esterna.
  • Il ciclo di vita della connessione DB è gestito da ContentProvider.
  • Passa facilmente URI di contenuti tra attività in un intento.
  • Semplici query in background tramite CursorLoader (o roll your own).

Contro :

  • Può essere fonte di confusione se non hai un buon esempio a portata di mano.
  • Se si dispone di uno sfondo Java aziendale, l’ORM potrebbe essere più familiare.

Quando stavo cercando di capire come implementare un ContentProvider, ho riversato il codice di esempio nell’applicazione I / O di Google . Prima di prendere una decisione, spenderei almeno un giorno per la prototipazione di uno in modo da poter ottenere un’esperienza di prima mano dei compromessi.

Consiglierei di spendere più tempo ed energie per scrivere il tuo ContentProvider. ContentProviders non riguarda solo la condivisione dell’accesso ai dati. I vantaggi

  • Hai modi di ascoltare i tuoi dati tramite ContentObservers
  • ContentProviders di per sé non sono thread-safe, ma è facile implementare thread-safetly
  • Ai cursori può essere chiesto di mantenersi aggiornati tramite notifyChange di notifyChange
  • È ansible aggiungere una buona astrazione senza influire sul livello aziendale. Ecco un esempio: utilizzi i contatti Android nella tua applicazione. Domani pianifichi di introdurre i tuoi contatti (tramite il tuo WebService). Il ContentProvider può essere modificato per assimilare questo requisito in modo molto aggraziato.
  • Le tabelle JOIN possono essere esposte molto bene con un design piacevole senza ingombrare il codice della tua business logic. Guarda alcuni dei ContentProvider Android come il MediaStore o il ContactsContract. Dai un’occhiata alle loro definizioni CONTENT_URI

Tutto sumto, ContentProvider è un concetto Android molto bello che vale la pena implementare. E una volta stabilite le definizioni, non è molto difficile aggiungere il supporto per più dati. Sarà quindi facile come scrivere il codice del tuo database in una class Helper o nelle tue classi di business logic.

** MODIFICA ** Ecco un’utilità che genera il codice del provider di contenuti dalle classi di modelli: https://code.google.com/p/mdsd-android-content-provider/

IMO: APK singolo == accesso diretto attraverso un livello di persistenza. Multple APK (o tuoi propri o che vogliono fornire l’accesso ai dati ad altre app) == Fornitore di contenuti per semplice necessità.