faire du SQL en Java

[harold50]

Bonjour

je développe une application en java qui doit interroger une base de donnée avec des requettes SQL.

je voudrais savoir si il y a un moyen de mettre des requettes SQL directement dans du code JAVA en tenant compte des variables de recherches entrée par l'utilisateur (nom de la table, collonnes ...).

merci

[Sentinel]

http://java.sun.com/docs/books/tutorial/jdbc/

[Bab00n]

en français pour débuter c'est moin violent !!

http://jguillard.developpez.com/JDBC/

http://java.developpez.com/IntroJDBC.pdf

parmi tant d'autre ... manque pas de doc la dessus sur le net ...

[fabien29200]

Heureusement qu'on peut le faire !

Sinon on irait pas bien loin.

Tu peux aussi rendre ton application indépendante de la base cible en utilisant Hibernate.

[beuhbeuh]

On ne met pas de requête SQL directement dans du code Java (ni dans aucun autre langage d'ailleurs <troll>sauf peut-être dans du PHP, mais c'est pas un vrai langage</troll>), jamais ! malheureux

Donc pour expliquer très rapidement, une bonne pratique de codage est de découper ton appli en couches dont une couche d'accès au données (ou DAL pour Data Access Layer). A partir de cette couche d'accès aux données, on génère des objets Java et ce sont ces objets que l'on manipule, jamais directement les données en base.

Je te laisse chercher dans Google avec ces mots clés (DAO ou DAL) au moins pour ta culture perso, vu que je suis conscient que c'est peut-être un peu hard pour un débutant, mais autant commencer sur de bonnes bases !

Après comme suggéré plus haut, on peut abstraire la couche d'accès aux données avec un O/R Mapper (Object/Relationnal Mapper : en gros faire le lien entre tes objets et ton modèle relationnel de base de données) comme Hibernate ou d'autres...

Je te laisse avec le mal de crâne

[sarx]

On ne met pas de requête SQL directement dans du code Java (ni dans aucun autre langage d'ailleurs <troll>sauf peut-être dans du PHP, mais c'est pas un vrai langage</troll>), jamais ! malheureux

hum, juste comme ca, Pro*C

[BreizFenrir]

Enfin j'espère bien que le préprocesseur Pro*C quand il passe la syntaxe SQL en C il fasse les opérations d'échappement bien comme il faut, que l'on ne se retrouve pas avec une application sensible aux injections. Et puis la syntaxe Pro*C sépare tout de même assez clairement la partie SQL de la partie C.

Mais je crois que je saisis ce que tu voulais dire, comme quoi beuhbeuh était peut-être un peu trop extrémiste dans ces propos, et que ces derniers disqualifient de fait des choses comme l'utilisation des PreparedStatements avec JDBC. D'ailleurs sans ORM il me semble me rappeler qu'il y a 2-3 façons de faire (ça y est, désappris mes cours de l'an dernier ) pour soumettre des requêtes en Java, mais il me semble qu'il y a toujours un bout de SQL apparaissant dans le code, bien que les requêtes soient protégées par tout un tas de vérifications.

Je me trompe ?

[sarx]

ué c'est ca.

enfin la ou en java tu dois passer par tout un tas d'objet pour executer une requete et recuperer le resultat (statement, resultset), en pro*c tout ca est gerer de facon plus ou moins transparente par le preprocesseur c

tu fais un truc du style directement dans ton programme

...

int a;

int b = 2

EXEC SQL select toto into :a from titi where truc = b;

...

plus qu'a utilisé la variable a comme tu veux, etant donné que c'est une variable classique c

enfin mon post etait justement en reponse au propos un peu extremiste comme quoi aucun langage ne pouvait integrer du sql directement, le pro*c a justemement ete concu pour ca

[fabien29200]

Je pense que les propos de beuhbeuh ont été mal interprétés.

Par "ne pas mettre de code directement dans du Java", il n'entendait pas dire qu'il ne faut pas écrire de SQL dans du Java, mais séparer les parties de code faisant les appels SQL dans une autre classe.

De cette manière la transformation BDD objet, n'est faite que dans une classe. Ce qui implique qu'un changement de table (fréquent sur un projet), il n'y a qu'une classe à vérifier.

Exemple concret :

un mauvais exemple (je squeeze les types et le détail d'un appel JDBC car ce n'est pas le propos) :

dans une JSP :

<select name="voitureChoisie">
<% res = exec("SELECT * FROM vehicule"); for (LigneSQL ligne : res) { println("<option value="+ligne.id + ">"+ligne.libelle+"</option>"); }%>
</select>

Ici on a exécuté une requête façon PHP (re troll lol) en plein dans le code de mise en page.

Un bonne pratique est donc de séparer les choses.

Par exemple:

Une classe VehiculeDAO, dans laquelle une méthode getVehicules

public List<Vehicule> getVehicules () {

List<Vehicule> res = new ArrayList<Vehicule>();

lignes = exec("SELECT * FROM vehicule"); 

for (LigneSQL ligne : lignes) { 

	res.add(new Vehicule(ligne.id, ligne.libelle);
}

  return res;
}

Ensuite quand a besoin de la liste des véhicules, on instancie la classe DAO et on exécute la méthode.

[beuhbeuh]

Merci pour cette explication, qui était effectivement sous tendue dans le reste de mon post (qu'il fallait lire pour comprendre la première phrase un peu provocatrice, je l'avoue)

Et le pro*c est un mauvais exemple, étant donné que le C n'est pas un langage orienté objet, le problème de l'utilisation de DAO ne se pose donc pas..

[BreizFenrir]

Tous ces exemples me rappellent le projet sur lequel j'ai commencé à bosser la semaine dernière au boulot. Des JSP avec des gros paquets de Java dedans (encore que ça pourrait être pire, il y a des classes appelées avant pour préparer certaines données). Des gros morceaux de code voire des classes inutilisées, et une classe dont les méthodes servent à faire les opérations sur la soixantaine de tables de la BDD. Une classe de 15 000 lignes. Et il me semble que les données entrées par l'utilisateur sont la plupart du temps directement concaténées avec le code SQL avant d'être refilées au code gérant la connexion.

Bref, voilà ce que ça donne quand les décideurs affectent trop peu de monde à un développement tout en demandant des ajouts/modifications/suppressions plusieurs fois par semaine.

Dieu merci, mon travail ne porte que sur l'interface. Même si voir ce genre de code me donne des envies de meurtres.

[max34]

Même si voir ce genre de code me donne des envies de meurtres.

Reprendre un code comme ça me fait plutôt deprimer

(et ensuite je pense aux meurtres )

[fabien29200]

On peut toujours essayer de se consoler en se disant qu'il y a pire ...

Lors d'un projet avec un prof de fac, j'ai bossé sur une appli en ADA (je ne connaissais pas ADA avant) en vi, sans commentaire dans le code, sans documentation. De plus, il y avait un genre de import.* au début de chaque classe, ce qui fait que pour retrouver d'où venait les méthodes appelées c'était grave galère. L'inefficacité poussée au maximum.

Ca reste ma pire expérience de projet :/