6
votes

JDBC portable vs SQLite sur Android

J'utilise SQLite dans un projet utilisé par une application Android. Actuellement, j'utilise l'implémentation SQLITE fournie dans android.database.sqlite .

Je veux faire une application de bureau qui utilise la même basebase. J'ai donc besoin de séparer tout le comportement partagé en projet / jar portable séparé.

Mon problème est que je suis en train de faire une utilisation intensive de android.database.sqlite . Si possible, je ne veux pas réécrire à nouveau chaque appel d'accès à la base de données à compatible avec JDBC ou autre que je devrai utiliser sans utiliser l'Android fourni SQLite.

Pour résoudre ce problème avec un impact minimal sur le code existant. J'intention d'écrire une interface SQLite (compatible avec android.database.sqlite ) que le code partagé utilisera ... sur Android, il sera implémenté de manière trivialité par android.database.sqlite , et sur le bureau, il sera implémenté par une certaine mutilation SQLite via JDBC pour correspondre android.database.sqlite . .

Ceci se révèle difficile car je fournis souvent objet [] pour être lié aux instructions préparées que JDBC nécessite une dactylographie stricte, et je ne connais pas le tout avec JDBC.

y a-t-il d'autre moyen d'utiliser SQLite en Java qui est similaire à android.database.sqlite ou toute autre approche qui peut me sauver l'effort (et le débogage inévitable) associé à la réécriture Beaucoup de points d'accès à la base de données?

Disclamer: Je n'ai jamais jusqu'à présent essayé d'utiliser JDBC.

Question simplifiée: Quelle est la meilleure façon d'utiliser SQLite en Java? JDBC, autre?


0 commentaires

3 Réponses :


4
votes

Je pense que la création d'une enveloppe serait une bonne idée, mais peut impliquer de nombreux efforts en termes de développement et de test. Peut-être que vous pouvez créer un projet sur Google et obtenir quelques personnes supplémentaires impliquées.

Sur une note latérale, je pense qu'il y a déjà un tel projet sur Google Code appelé SQLLROID


1 commentaires

Merci pour le lien, il semble prometteur. Je pensais à faire de l'interface inverse 'JDBC ressemblant à SQLite', par opposition à l'autre, ce qui ne semblait pas être fonctionnel.



0
votes

Vous pouvez créer quelque chose comme un Datamappper pour votre domaine, ce qui prolonge ainsi le modèle BCE à BCDE. Le rôle d'une mappeuse de données est de résumé de la technologie de base de données sous-jacente afin d'augmenter la réutilisation ultérieure


0 commentaires

1
votes

Voici ce que je ferais:

  1. Créez une interface pour les opérations de base de données. Il inclurait des méthodes pour ajouter, modifier, supprimer des enregistrements et enregistrer / s'engager si nécessaire. Cette interface pourrait être étendue au besoin.
  2. Créez une implémentation pour JDBC / SQLite. Avoir une entrée de configuration pour sélectionner la mise en œuvre appropriée de préférence à la hauteur de la construction.

    Qu'est-ce que cela signifie dans votre cas est:

    1. Créez l'interface.
    2. créer une implémentation qui utilise de manière interne à SQLite.
    3. Créer une implémentation qui utilise à l'interne à une implémentation de la JDBC.

      De cette façon, votre application sera extraite de la base de données sous-jacente utilisée. Cela améliorera la portabilité.


2 commentaires

Je ne sais pas si vous voulez dire une interface spécifique de domaine. Si oui, le problème serait que je devrais réactiver les liaisons pour chaque projet (pensant à l'avance). Sinon, cela ressemble à nouveau à un gaspillage dans ce JDBC est supposé comme ça ... pourquoi recréer la roue. Mais je pense que votre philosophie a raison, +1.


@Akusete, il parle du motif Dao