Discussion :

[blueman1]

Etant donné que:

- tomcat implémente les "pools de connexions" (cf. le très bon tutorial sur ce site)
- mysql accepte plusiseurs connexions simultanées (vive le multithread)

Je me pose très sincèrement la question de la pertinence du singleton.

[dinobogan]

Le singleton est un Design Pattern. Je ne voit pas le rapport avec l'accès à la base de données.

[tchize_]

aucun rapport entre le singleton et le design pattern. De plus, il y a eu une logue discussion au sujet de la pertinence des singletons sur ce forums il y a pas si longtemps. Je te suggère d'utiliser la fonction rechercher.

[blueman1]

Effectivement beaucoup de débats...pour tous les langages OO. Aucun n'apporte pourtant de réponse concrète à la question.

Je lis d'un coté:

Un singleton pour une connexion à la base de données est une grosse erreur de conception, à fortiori dans un environnement ASP.NET intrinséquement multi-threadé.

Je vois de l'autre:

j'ai implementé un sigleton pour ma classe DAO

Je ne suis pas sur de percevoir un intérêt réel au singleton. Je vais donc formuler deux question précises:

Question 1:

Pourquoi une grande majorité de programmeurs utilisent le pattern Singleton pour impléenter leur classe d'accès au SGBD ? Intérêt ? Impact sur les performances ?

Question 2 (plus propre à l'implémentation du apttern singleton):

Pourquoi faire un "singleton" (donc j'imagine avec double vérification que l'insance est "null") et non une simple classe statique pour une classe DAO ?

Merci a tous ceux qui seront capables de répondre de manière claire et concise.

[TheJoe]

Salut,
Pour la première question, je pense que d'une manière générale un singleton permet de gagner de l'espace mémoire puisqu'on a le meme instance qui est utilisée par toutes les autres instances du programme, et qui un gain en temps de réponse puisqu'on va aller chercher directement une instance existante au lieu d'en créer une depuis le début. (Le processus d'instantiation est assez lourd). Puisque les acces en base sans nombreux l'utilisation d'un singleton semble plus optimale.

Pour la deuxieme question, un singleton est implémenté en utilisant des variables statiques. Seulement en utilisant le singleton, les autres classes n'ont plus en charge la gestion de cette variable. C'est le singleton qui gère les variables statiques qui sont "dedans" notament leurs cycles de vies.

J'espere que j'ai pas dit de betises.

[tchize_]

pourquoi un DAO singleton alors qu'on a les connection pool? Ben tu touren autour du pot, l'accès au connection pool doit se faire par une classe ou une autre. Dans des webapps, le pool (qui peut etre vu comme une isntance unique de 'pool' sur un db précise) est géré par le conteneur, et là c'est mieux qu'un singleton qui gère la connection. Dans les applis standalone, c'est souvent le contraire.

pourquoi le singleton d'une manière générale: quand tu veux partager une isntance avec plein d'objets utilisateurs.

pourquoi pas une classe statique avec méthodes statique? Le pattern singleton est un pattern qui permet de garantir *une* et *une seule* instance. Il ne faut pas le confondre avec une classe utilitaire (qui elle, typiquement, n'a que des méthodes statiques, donc sans état).
De plus un signelton peut implémenter des interface, ce que ne peux pas faire une classe purement statique (on ne sais pas définir de méthode statique dans un classe). Enfin, contrairement à une classe utilitaire, on a parfois besoin de faire un descendant d'un singleton ou de passer ce singleton en paramètre à une méthode.

[dinobogan]

aucun rapport entre le singleton et le design pattern.

Désolé, je ne comprends pas. Le singleton n'est pas un design pattern ?

[tchize_]

désolé, j'écrit trop vite, je voulais dire "aucune rapport entre le singleton et la gestion de la connection"