2010-08-11 12 views
5

Estoy usando SQLite en un proyecto utilizado por una aplicación de Android. Actualmente estoy usando la implementación de SQLite proporcionada en android.database.sqlite.JDBC portátil vs SQLite en Android

Quiero hacer una aplicación de escritorio que use la misma base de código. Entonces, necesito separar todo el comportamiento compartido en un proyecto/jar portable separado.

Mi problema es que actualmente estoy haciendo un uso intensivo de android.database.sqlite. Si es posible, no quiero volver a escribir cada llamada de acceso a la base de datos para que sea compatible con JDBC o lo que sea que tenga que usar sin usar el SQLite proporcionado por Android.

Para resolver este problema con un impacto mínimo en el código existente. Tengo la intención de escribir una interfaz SQLite (compatible con android.database.sqlite) que el código compartido usará ... en Android se implementará trivialmente por android.database.sqlite, y en el escritorio se implementará mutilando de alguna manera SQLite a través de JDBC para que coincida con android.database.sqlite.

Esto está resultando difícil ya que a menudo proporciono matrices Object[] para vincularlas a declaraciones preparadas que JDBC requiere un tipado estricto, y no estoy familiarizado con JDBC en absoluto.

¿Hay alguna otra forma de utilizar SQLite en Java que sea similar a android.database.sqlite, o cualquier otro enfoque que pueda ahorrarme el esfuerzo (y la depuración inevitable) asociados con volver a escribir muchos puntos de acceso a la base de datos?

Disclaimer: Nunca he intentado utilizar JDBC hasta ahora.

Pregunta simplificada: ¿Cuál es la mejor manera de usar SQLite en java? JDBC, otro?

Respuesta

3

Creo que crear una envoltura sería una buena idea, pero puede implicar un gran esfuerzo en términos de desarrollo y de prueba. Tal vez puedas comenzar un proyecto en google y involucrar a algunas personas más.

En una nota lateral, creo que ya hay un proyecto de este tipo en el código de Google llamado sqldroid

+0

Gracias por el enlace, parece prometedor. Estaba pensando en hacer que la interfaz inversa 'JDBC se viera como SQLite', a diferencia de la otra, que no parecía viable. – Akusete

0

Usted puede crear algo así como un DataMapper de tu dominio para extender el patrón BCE a Bcde. El papel de un asignador de datos es hacer abstracción de la tecnología de base de datos subyacente para el aumento de la reutilización posterior

1

Aquí es lo que haría:

  1. crear una interfaz para las operaciones de bases de datos. Incluiría métodos para agregar, modificar, borrar registros y guardar/confirmar si es necesario. Esta interfaz podría extenderse cuando sea necesario.
  2. Cree una implementación para JDBC/SQLite. Tener una entrada de configuración para seleccionar la implementación adecuada preferiblemente en tiempo de compilación.

Lo que esto significa en su caso es:

  1. crear la interfaz.
  2. Crea una implementación que hace uso interno de SQLite.
  3. Cree una implementación que internamente haga uso de alguna implementación de JDBC.

De esta manera, su aplicación se abstraerá de la base de datos subyacente que se está utilizando. Esto mejorará la portabilidad.

+0

No estoy seguro si se refiere a una interfaz específica de dominio. Si es así, entonces el problema sería que tendría que volver a hacer los enlaces para cada proyecto (pensando en el futuro). Si no, entonces eso nuevamente parece un desperdicio porque se supone que JDBC es solo eso ... ¿por qué volver a crear la rueda? Pero creo que tu filosofía es correcta, +1. – Akusete

+0

@Akusete Está hablando del patrón DAO – naikus