android - studio - ¿Cómo decidir entre el acceso directo a la base de datos y el proveedor de contenido?
manual de java para android (3)
Estoy escribiendo una aplicación que consta de lógica de negocios y partes de UI. Hay una gran cantidad de datos para almacenar y acceder / modificar tanto por BL como por UI. En la mayoría de los casos, los cambios en los datos almacenados deben reflejarse en la interfaz de usuario de inmediato.
¿Cómo decido si debo o no usar el acceso directo a la base de datos? ¿proveedor de contenido?
He leído algo sobre el tema ( 1 , 2 ) y comprendo la diferencia entre estas dos opciones.
Comparta sus opiniones sobre otros aspectos del problema, como el rendimiento, el nivel de dificultad del desarrollo del código y la capacidad de mantenimiento, etc.
En las aplicaciones que he escrito, he encontrado que una vez que pasas la curva de aprendizaje, implementar un ContentProvider es bastante fácil.
Pros :
- No hay dependencias externas.
- El ciclo de vida de la conexión de base de datos es manejado por el ContentProvider.
- Pase fácilmente los URI de contenido entre actividades en una intención.
- Consultas de fondo simples a través de CursorLoader (o ruede las suyas propias).
Contras :
- Puede ser confuso si no tienes un buen ejemplo a la mano.
- Si tiene un fondo Java empresarial, es posible que ORM sea más familiar.
Cuando estaba tratando de averiguar cómo implementar un ContentProvider, coloqué el código de ejemplo en la aplicación de E / S de Google . Antes de tomar una decisión, al menos me pasaría un día creando un prototipo para que pueda obtener una experiencia de primera mano de las compensaciones.
IMO: Single APK == acceso directo a través de una capa de persistencia. Múltiples APKs (ya sean propios o que deseen proporcionar acceso a los datos a las aplicaciones de otros) == Proveedor de contenido por simple necesidad.
Recomendaría gastar ese tiempo y energía extra para escribir su Proveedor de contenido. Los proveedores de contenido no se limitan a compartir el acceso a los datos. Las ventajas
- Tiene formas de escuchar sus datos a través de
ContentObservers - Los proveedores de contenido por sí mismos no son seguros para subprocesos, pero es fácil de implementar de forma segura para subprocesos
- Se les puede pedir a los cursores que se mantengan actualizados a través del ContentProvider''s
notifyChange - Puede agregar una buena abstracción sin afectar su capa de negocios. Aquí hay un ejemplo: utiliza los contactos de Android en su aplicación. Mañana planea introducir sus propios contactos (a través de su propio servicio web). El 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. Echa un vistazo a algunos de los proveedores de contenido de Android como MediaStore o ContactsContract. Echa un vistazo a sus definiciones CONTENT_URI
En general, un ContentProvider es un concepto de Android muy hermoso que vale la pena implementar. Y una vez que haya establecido sus definiciones, 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 ayudante o sus clases de lógica de negocios.
** EDIT ** Aquí hay una utilidad que genera código de proveedor de contenido a partir de clases modelo: https://code.google.com/p/mdsd-android-content-provider/