Faire un bon DAO

Bonjour à tous, même si j'utilise Spring dans mon exemple, mon cas et ma question se veulent plus générique, je cherche à savoir ou stocker mes requêtes (Je parle ici de la requete SQL stocké dans un String ou StringBuffer)
Actuellement, c'est la manière que j'utilise

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public Categorie getCategorie(int categorieId){ StringBuffer query=new StringBuffer(); query.append("SELECT categorieId"); query.append(" ,categorieName"); query.append(" FROM categorie"); query.append(" WHERE categorieId=?"); //L'appel utilise JdbTemplate mais cela n'a pas d'importance return getJdbcTemplate().queryForObject(query.toString(), mapperCategorie, categorieId); }

---

Dans ce cas, à chaque appel, j'instancie un objet StringBuffer.
Est-ce qu'il ne serait pas mieux ou conseillé d'instancier ma query dans le constructeur de ma classe, et de l'appeler.

Les 2 systèmes ont des avantages et des inconvénients: La première est un peu plus lente, alors que la deuxième conserve les query en mémoire, qu'en pensez-vous?


D

Dans la mesure où ta requête est statique, je ne vois pas trop l'intérêt de passer par un StringBuffer (ou StringBuilder...).
Autant utiliser une constante ou un littéral...

L'autre question pourrait être : où stocker ces constantes...
Là, on peu imaginer plusieurs méthodes dont :
- la chaîne de caractère directement dans le query (ce que tu proposes)
- un fichier de propriétés
- un fichier xml (bof, je préfère le fichier de propriétés)
- une classe avec propriétés static
- etc...

En effet, dans mon cas, j'ai utilisé StringBuffer parce que j'ai repris une requête de mon projet que j'ai simplifié ensuite.

Mais si on prend l'exemple d'un String. Je suis pas fan des fichiers propriété ou tu sais plus trop ou c'est utilisé,

Moi j'avais pensé soit utilisé un traditionnel

public static final String marequete1="MON SELECT ...";

Ou alors, comme j'utilise l'injection de dépendance de Spring, mettre mon attribut private propre à mon objet instancié

private String ma requete

et l'initialiser dans mon Constructeur.

Je sais pas si y'a une différence au niveau mémoire entre une variable static ou une variable privé d'un objet instancié sachant que Spring m'assure que mon objet n'est instancié que la première fois. Mon application utilise toujours le même objet.

Cela suppose par contre, que même mes requêtes peu utilisé soit toujours là quelques part en mémoire:calim2: (Inquiétant non :D)

D'avance merci pour vos réponses.

Je ne pense pas qu'il y ait une (grosse) différence entre une propriété static d'une classe et une propriété initialisée par Spring (ou les 2 ensembles, ce qui est mieux si on veut partager ces informations entre plusieurs classes)

C'est mon avis, je peut me tromper, c'est pour cela que je demande ici

Pour le moment, je n'avais envisager de faire appels à mes requêtes que dans la classe. C'est à dire que par exemple, les requêtes concernant la récupération de "Categorie" ne sont appelé que par mes fonctions de ma classe CategorieDao

Mais maintenant que vous le dites, en supposant des utilisations par des classes extérieures,et selon les règles du principe d'injection de dépendance de Spring, il s'agirait d'un véritable sacrilège si je me mettais à appeler directement des variables statiques d'une autre classe non?

Dans la mesure où on cible les DAO par "entité", l'intérêt de partager une requête concernant une DAO avec une autre n'a pas beaucoup de sens.
On mon avis, l'injection simple avec Spring (si déjà tu l'utilises) suffit largement pour rendre les choses souples...

Bonjour,

à noter que tous ce qui est static final String devienent des littéraux après compilation (pas que les Strings d'ailleurs). Donc il n'y a pas vraiment de différence entre les deux.

Par contre pour injecter la requête par spring je vois pas l'intéret. Le XML c'est pas sexy à maintenir.

Citation:

---

Envoyé par Alain Defrance

Par contre pour injecter la requête par spring je vois pas l'intéret. Le XML c'est pas sexy à maintenir.

---

Certes, mais va le dire à tous ceux qui l'imposent, dont Spring...
Pas pour rien qu'on parle de XM-Hell :aie:

Citation:

---

Envoyé par OButterlin

Certes, mais va le dire à tous ceux qui l'imposent, dont Spring...
Pas pour rien qu'on parle de XM-Hell :aie:

---

Héhé, Ca a l'avantage de bien séparer les données du code, mais bon là pour une requête j'ai le sentiment que c'est un peu abusé. Une constante voir une peropertie ferait tout à fait l'affaire :p

Rassurez-vous, je n'irais pas exporter mes requêtes dans du xml.(Il n'y a aucun interêt à cela)
Ce que je parlais avais Spring, c'était du fait que Spring m'instancier un objet CategorieDao, et donc que je pourrais avoir des variables de mon objet, que j'instancie dans le constructeur qui lui sera appelé par Spring au chargement de son contexte d'application.
Cela me parait un bon compromis entre mes requetes String statiques(J'aime pas personnellement) et instancier mes String requetes à chaque fonction.