Proveedor de contenido vs acceso directo a la base de datos (gestión de transacciones)

Question

Entiendo, al menos en papel, la diferencia básica entre el proveedor de contenido y el acceso directo a SQLiteDatabase. Tengo un prototipo funcional para mi aplicación, y actualmente solo está golpeando directamente la base de datos. Realmente no tengo experiencia en el uso del patrón Proveedor de contenido, pero he descubierto que tendré que compartir algunos datos con otra aplicación.

Solo compartiré aproximadamente 2 de una docena de tablas, así que me preguntaba si debería estar rehaciendo completamente la capa de datos para seguir el patrón del proveedor de contenido, o simplemente expongo solo esas tablas a través de un proveedor de contenido por el bien de la otra aplicación y todavía acceder directamente a la base de datos en la aplicación principal.

Uno de los problemas que encontré con mi prototipo fue que tengo algunas transacciones bastante complejas, y el código que escribí para que funcione no está diseñado especialmente bien y no es reutilizable en absoluto. A medida que agregue más funcionalidades a esta aplicación, voy a necesitar una capa de acceso a datos mejor diseñada, antes de comenzar a escribir la mía, ¿alguien sabe ya de buenos recursos con patrones de diseño para este tipo de cosas? Además, si necesito ir a la ruta del proveedor de contenido, ¿tendré un control sólido sobre las transacciones de la base de datos?

Answer 1

No creo que deba tener un problema simplemente creando un proveedor de contenido con la funcionalidad que necesita que se encuentra sobre su código de base de datos directa. Un proveedor de contenido es solo una abstracción para acceder a datos estructurados que se parece mucho a SQLite. :) Si varias partes internas de la aplicación acceden directamente a la misma base de datos que el proveedor, siempre que el código de las dos se reproduzca correctamente, debería estar bien.

En realidad, no soy partidario de ser absoluto acerca de "siempre debes usar proveedores de contenido". Si no necesita un proveedor de contenido, no use uno; simplemente dirija SQLite si es más fácil. Si necesita un proveedor de contenido para alguna interacción específica con otras aplicaciones, siéntase libre de escribir una solo para eso sin que sea una tarea complicada que admita todo lo que su aplicación hace internamente con la base de datos. Si esto es más fácil, genial. También hace que sea mucho menos probable que exponga involuntariamente datos privados de su aplicación a otros.

Answer 2

No me explique esto, pero estoy bastante seguro de que un proveedor de contenido es una forma de abstraer la forma en que está proporcionando datos a un objeto. De esta forma, su objeto solo puede comunicarse con el proveedor y no le importa la implementación, es decir, cómo y dónde se almacenan los datos. Quizás desee proporcionar alguna otra forma de almacenar sus datos en el futuro, y usar el paradigma del proveedor de contenido le ahorrará toneladas de reprocesamiento, ya que es solo una comunicación basada en la interfaz.

Utilizaría los patrones de diseño de Android en cualquier lugar que pudiera. Para ser sincero, mirándolo ahora, realmente debería estar haciendo esto en mi proyecto.