2012-06-23 8 views
0

Je ne veux pas que mon code soit couplé à un pilote JDBC (par exemple MySql). Je veux faire du code universel, qui peut fonctionner avec de nombreuses implémentations de bases de données. Et je ne comprends pas très bien comment atteindre cet objectif en utilisant JDBC.Comment réaliser un couplage lâche entre les pilotes JDBC et le code source?

Je pense que pour atteindre ce que j'ai besoin que d'exporter le nom de classe du pilote (et chaîne de connexion) au fichier .properties (par exemple "com.mysql.jdbc.Driver"), puis dans le code utiliser comme ceci Class.forName(PROPERTIES.getDriverName()).newInstance(); Alors, quand je décide de changer ma base de données, tous les ce que j'ai besoin de changer est le nom du pilote jdbc dans le fichier .properties (par exemple à "COM.ibm.db2.jdbc.app.DB2Driver"), la chaîne de connexion, et changer le fichier .jar du pilote dans le classpath.

Est-ce vrai?

+1

En théorie, c'est bien, mais selon mon expérience (1) Vous ne changez vraiment pas de bases de données sauf dans des circonstances extrêmement rares; (2) C'est la syntaxe SQL qui rendra difficile, pas le pilote. – JohnFx

+0

@JohnFx ok, merci, mais si ne faites pas attention à la différence entre la syntaxe sql, donc cette idée est bonne? Ou peut-être exister un moyen plus élégant pour atteindre cet objectif? – MyTitle

+0

Peut être le déplacer vers datasource? – kosa

Répondre

3

Le couplage lâche peut être réalisé de plusieurs façons -

A. Utilisez Hibernate, mais cela peut-être trop pour vos besoins et a nui au rendement (si votre application effectue la plupart du temps écrire opération)

B. Utilisez Printemps- JDBC ou tout autre framework qui sert de wrapper JDBC - généralement ils fournissent une sorte d'abstraction

C. Si votre code est du code Java EE, vous pouvez travailler avec DataSources, et les configurer sur votre serveur d'applications Java - vous allez chercher le source de données par nom, et vous ne connaîtrez pas les détails de mise en œuvre derrière

D. Vous c assurez-vous de construire l'application en couches - une couche logique métier qui utilise une couche d'accès aux données, qui utilise un moteur de données (assurez-vous que votre classe de moteur de données implémente une interface vous permettant de modifier facilement l'implémentation).

Votre classe de moteur de données peut lire les informations sur le pilote jdbc à partir d'une configuration (propriétés des fichiers XML) - c'est essentiellement ce que fait Hibernate, par exemple.

+1

Dans l'approche 'D', envisagez de rendre l'interface conforme au [_strategy pattern_] (http://en.wikipedia.org/wiki/Strategy_pattern). – trashgod

+0

@trashgod - merci pour le commentaire. Je suis totalement d'accord avec vous –

1

Cela pourrait fonctionner pour vous, bien sûr. Je serai cependant un peu plus complet pour les futurs lecteurs de la question:

mais beaucoup de requêtes que vous écrivez peuvent être spécifiques à une base de données, ou s'appuyer sur certains mots-clés pour être efficaces. Prenons par exemple une requête commune. Vous voulez la liste de tous les produits dans une base de données, mais montrer à l'utilisateur 10 à un moment:

MySQL:

select * from products LIMIT 0,10 

puis pour les 10 lignes suivantes:

select * from products LIMIT 10,10 

etc.

Fantastique, les utilisateurs peuvent utiliser MySQL pour la base de données. Eh bien, que se passe-t-il s'ils utilisent postgres, une autre base de données gratuite et très populaire? Cette requête ne va pas fonctionner:

SELECT * FROM product LIMIT 10 OFFSET 10 

Votre code n'est donc pas aussi portable que vous le pensez. Une façon de contourner ce problème est de créer vos propres interfaces (interface Query, interface Access) pour toutes les requêtes/accès que vous envisagez de faire, et d'avoir une fabrique de requêtes qui peut instancier, en fonction du dialecte DB. (MySQL, postgres, etc) et créer MySQLQueryImpl et PostGresQueryImpl (les deux implémentant l'interface de requête).

Vous devez malheureusement coder certains des appels de base de données, ou les déplacer dans un fichier de propriétés. Vous pouvez également concevoir le facteur de requête à instancier à partir d'un fichier de propriétés (comme vous le souhaitez) et autoriser les autres utilisateurs à implémenter leur propre requête afin que l'extensibilité soit présente et que vous n'ayez pas à tout faire vous-même.

Ou ...

L'autre option, ce qui est probablement plus élégante et la preuve d'erreur (bien ... peut-être) est de laisser quelqu'un d'autre le faire pour vous. Hibernate est un outil très commun qui résume la base de données en lecture/écriture pour vous, et peut être configuré pour utiliser une base de données différente comme vous le souhaitez, seulement il a des années d'expérience et des corrections de bugs. Ce n'est pas la chose la plus facile à apprendre (pour les requêtes complexes et les jointures, etc.) mais pour les modèles de base et le mappage vers une base de données, cela vous donnera tout ce que vous voulez et plus encore. chargement de données afin de ne pas apporter des milliers d'enregistrements que vous n'utiliserez pas.Il vous faudrait beaucoup de temps pour créer et durcir un système comme celui-ci.

2

Vous l'avez compris. Externaliser le nom de la classe de pilote, l'URL de la base de données, l'utilisateur et le mot de passe, et c'est parti. C'est ce que font la plupart des «frameworks»: les serveurs Java EE permettent de configurer les sources de données sur le serveur et d'y accéder en utilisant JNDI. Hibernate a des entrées dans son fichier de configuration, les pools de connexions utilisent généralement un fichier XML ou un fichier de propriétés pour conserver leur configuration.

Bien sûr, si vous utilisez du code SQL propriétaire, vous ne pourrez pas passer facilement d'une base de données à une autre, mais c'est un autre problème.

1

La chaîne de connexion d'externalisation ne permet pas à votre application de gérer différentes bases de données. Mais voici ce que vous pouvez faire.

Utiliser au lieu de connexion Datasource Cela vous offre la possibilité de créer connexion de différentes façons en utilisant JNDI, de Connection Pool, etc.

Plus d'informations sur la source de données, tout droit sorti de javax.sql.DataSource javadoc

Une fabrique pour les connexions à la source de données physique que représente cet objet DataSource . Une alternative à l'installation DriverManager , un objet DataSource est le moyen préféré d'obtenir une connexion .

Définissez l'interface DAO pour accéder aux données. Faites dépendre votre code d'application sur Interface. Vous pouvez fournir une implémentation spécifique à la base de données pour l'interface DAO. Lorsque la base de données change, créez une nouvelle implémentation pour la base de données. Laissez DAO usine choisir et choisissez l'instance appropriée de DAO selon la base de données.

Les bibliothèques comme Mybatis, Hibernate qui supportent ORM paradigm automatisent ces étapes pour vous.

Questions connexes