J'ai une application MDI dont presque toutes les fenetres enfants doivent
accéder à une base de données Sql Server. Quelle est la meilleure tactique?
Une connexion par fenetre enfant ou une connexion dans la fenetre mère
passèe en paramètre aux fenetres enfants lors de leur création?
Moi, je pencherais du coté du singleton, voir du membre static d'une classe business.
-- Paul Bacelar
"Fabian Vilers" wrote in message news:42cce95c$0$1822$
Bonjour à tous,
J'ai une application MDI dont presque toutes les fenetres enfants doivent accéder à une base de données Sql Server. Quelle est la meilleure
tactique?
Une connexion par fenetre enfant ou une connexion dans la fenetre mère passèe en paramètre aux fenetres enfants lors de leur création?
Merci pour vos conseils
mboizeau
A mon sens , il semble plus pragmatique d'utiliser une connection unique. On peut choisir de la passer en paramètre de chacun des formulaires. Ou, effectivement on peut la mutualiser au travers d'une classe métier dont elle est une propriété statique. Cela signifie que les formulaires ne contiennent plus que de "l'interface" et ne font que manipuler les objets de donnée fournies par la classe métier.
a+
Marc Boizeau
http://oraclevsmicrosoft.blogspot.com
PS: Paul je ne vois pas bien l'intéret du singleton dans le cas d'une appli MDI winform. Tu pensais à quoi?
A mon sens , il semble plus pragmatique d'utiliser une connection
unique.
On peut choisir de la passer en paramètre de chacun des formulaires.
Ou, effectivement on peut la mutualiser au travers d'une classe
métier dont elle est une propriété statique. Cela signifie que les
formulaires ne contiennent plus que de "l'interface" et ne font que
manipuler les objets de donnée fournies par la classe métier.
a+
Marc Boizeau
http://oraclevsmicrosoft.blogspot.com
PS: Paul je ne vois pas bien l'intéret du singleton dans le cas
d'une appli MDI winform. Tu pensais à quoi?
A mon sens , il semble plus pragmatique d'utiliser une connection unique. On peut choisir de la passer en paramètre de chacun des formulaires. Ou, effectivement on peut la mutualiser au travers d'une classe métier dont elle est une propriété statique. Cela signifie que les formulaires ne contiennent plus que de "l'interface" et ne font que manipuler les objets de donnée fournies par la classe métier.
a+
Marc Boizeau
http://oraclevsmicrosoft.blogspot.com
PS: Paul je ne vois pas bien l'intéret du singleton dans le cas d'une appli MDI winform. Tu pensais à quoi?
Si je me souvient de ce que j'ai vu dans les WebCast ADO.NET de Microsoft, ADO.Net implémente un pool de connexions. En gros, ça veut dire qu'il ne ferme pas et n'ouvre pas toujours la connexion quand tu lui demande. ADO.NET essaye d'optimiser les connexions à ta place. Dans ton code tu continue à ouvrir et fermer ta connexion à la demande et ADO.NET optimise... C'est pas beau ça...
Exemple: dans ton code, tu ouvre et tu ferme 10 fois de suite la connexion à la base, mais ADO.NET n'en ouvre et n'en ferme qu'une seule.
Mais bon j'ai jamais eu besoin pour le moment (donc pas testé). Tu trouvera plus d'infos sur les webcast des rencontres ADO.NET.
J'ai une application MDI dont presque toutes les fenetres enfants doivent accéder à une base de données Sql Server. Quelle est la meilleure tactique? Une connexion par fenetre enfant ou une connexion dans la fenetre mère passèe en paramètre aux fenetres enfants lors de leur création?
Merci pour vos conseils
Bonjour,
Si je me souvient de ce que j'ai vu dans les WebCast ADO.NET de
Microsoft, ADO.Net implémente un pool de connexions. En gros, ça veut
dire qu'il ne ferme pas et n'ouvre pas toujours la connexion quand tu
lui demande. ADO.NET essaye d'optimiser les connexions à ta place. Dans
ton code tu continue à ouvrir et fermer ta connexion à la demande et
ADO.NET optimise... C'est pas beau ça...
Exemple: dans ton code, tu ouvre et tu ferme 10 fois de suite la
connexion à la base, mais ADO.NET n'en ouvre et n'en ferme qu'une seule.
Mais bon j'ai jamais eu besoin pour le moment (donc pas testé). Tu
trouvera plus d'infos sur les webcast des rencontres ADO.NET.
J'ai une application MDI dont presque toutes les fenetres enfants doivent
accéder à une base de données Sql Server. Quelle est la meilleure tactique?
Une connexion par fenetre enfant ou une connexion dans la fenetre mère
passèe en paramètre aux fenetres enfants lors de leur création?
Si je me souvient de ce que j'ai vu dans les WebCast ADO.NET de Microsoft, ADO.Net implémente un pool de connexions. En gros, ça veut dire qu'il ne ferme pas et n'ouvre pas toujours la connexion quand tu lui demande. ADO.NET essaye d'optimiser les connexions à ta place. Dans ton code tu continue à ouvrir et fermer ta connexion à la demande et ADO.NET optimise... C'est pas beau ça...
Exemple: dans ton code, tu ouvre et tu ferme 10 fois de suite la connexion à la base, mais ADO.NET n'en ouvre et n'en ferme qu'une seule.
Mais bon j'ai jamais eu besoin pour le moment (donc pas testé). Tu trouvera plus d'infos sur les webcast des rencontres ADO.NET.
J'ai une application MDI dont presque toutes les fenetres enfants doivent accéder à une base de données Sql Server. Quelle est la meilleure tactique? Une connexion par fenetre enfant ou une connexion dans la fenetre mère passèe en paramètre aux fenetres enfants lors de leur création?
