cómo decidir entre el acceso directo a la base de datos y el proveedor de contenido?

Question

Estoy escribiendo una aplicación que consta de partes de lógica de negocios y UI. Hay una gran cantidad de datos para ser almacenados y accedidos/modificados por BL y UI. En la mayoría de los casos, los cambios en los datos almacenados deben ser reflejados por la IU inmediatamente.

¿Cómo decidir si debería o no debería utilizar el acceso directo DB? ¿proveedor de contenido?

He leído algo sobre el tema (1, 2) y entiendo la diferencia entre estas dos opciones.

Por favor comparta sus pensamientos sobre otros aspectos del problema, como el rendimiento, el nivel de dificultad de desarrollo de código y facilidad de mantenimiento, etc.

Answer 1

En las aplicaciones que he escrito, he encontrado que una vez que pasas la curva de aprendizaje, la implementación de un ContentProvider es bastante fácil.

Pros:

• Sin dependencias externas.
• El ciclo de vida de la conexión de base de datos es gestionado por ContentProvider.
• Transfiera fácilmente los URI de contenido entre las Actividades de un Intento.
• Consultas de fondo simples a través de CursorLoader (o hazlo por ti mismo).

Contras:

• puede ser confuso si usted no tiene un buen ejemplo práctico.
• Si tiene un fondo Java empresarial, ORM podría estar más familiarizado.

Cuando estaba tratando de descubrir cómo implementar un ContentProvider, volqué sobre el código de ejemplo en la aplicación Google's I/O. Antes de tomar una decisión, al menos pasaría un día creando un prototipo para que pueda obtener experiencia de primera mano de las compensaciones.

Answer 2

IMO: APK individual == acceso directo a través de una capa de persistencia. Archivos APK múltiples (ya sea los suyos o que quieran proporcionar acceso a los datos a las aplicaciones de los demás) == Proveedor de contenido por simple necesidad.

Answer 3

Recomendaría gastar ese tiempo y energía extra para escribir su ContentProvider. ContentProviders no solo se trata de compartir el acceso a los datos. Las ventajas

• Usted tienen formas de reproducir sus datos a través de ContentObservers
• ContentProviders por sí mismos no son seguro para subprocesos, pero es fácil de implementar hilos safetly
• cursores se puede pedir a mantenerse hasta -to-día a través de notifyChange
• puede añadir buena abstracción del ContentProvider sin afectar a la capa de negocio. Aquí hay un ejemplo: usted usa los contactos de Android en su aplicación. Mañana planea introducir sus propios contactos (a través de su propio servicio web). ContentProvider se puede modificar para asimilar este requisito de una manera muy elegante.
• Las tablas de JOIN se pueden exponer muy bien con un diseño agradable sin saturar su código de lógica de negocios. Eche un vistazo al Android ContentProvider como MediaStore o ContactsContract. Echa un vistazo a sus definiciones CONTENT_URI

En conjunto, ContentProvider es un concepto Android muy bonito que vale la pena implementar. Y una vez que tenga sus definiciones en su lugar, no es muy difícil agregar soporte para más datos. Entonces será tan fácil como escribir el código de su base de datos en una clase de Ayuda o en las clases de lógica de negocios.

** ** EDITAR Aquí es una utilidad que genera el código de proveedor de contenido de las clases del modelo: https://code.google.com/p/mdsd-android-content-provider/