Ressource de connexion MySQL

Frederic Rouchouze wrote:

Afin de programmer "proprement", dois-je passer systématiquement en argument
à mes créateurs de classes une ressource de connexion ?
Ou bien dois-je utiliser la possibilité de la fonction mysql_query() qui est
la suivante : "Si link_identifier n'est pas précisé, la dernière connexion
est utilisée" ?

Je te dirais que c'est fonction de ton utilisation: si tu n'utilise
qu'une base, il n'y a aucun intérêt à t'inquiéter de la ressource de
connexion vu que tu utiliseras toujours la même.

Si par contre tu dois utiliser des bases distinctes, dans ce cas il te
faut t'en inquiéter. Et dans ce cas, pourquoi ne pas utiliser tes
connexions en variable globales si tu en as besoin fréquemment?

--
Découvrez Original War: http://www.original-war.org
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.crazy-irc.net

Merci de me donner votre avis,

* il s'agit ici d'un probleme de conception objet.
* l'identifiant d'une BD est une ressource (php), a ce titre elle
peut tres bien etre passée par valeur puisqu'il s'agit juste d'un
nombre (id).
* si tu veux creer un systeme de classes, il est tout de meme
un peu ennuyeux de se limiter à une seule base de données, meme
si les cas d'utilisation de plusieurs bases sont assez rares.

maintenant voici comment cela peut se concevoir :

class Db {
var $db; # l'identifiant de connection

function Db(... les params){
$this->db = $this->db_connect();
}

function db_connect(){
# methode virtuelle
}

function query($sql){
# fonction virtuelle
}
}


class DbMysql extends Db {

function db_connect(...){
return mysql_connect(...);
}

function query($sql){
return mysql_query($this->db, $sql);
}
}

utilisation

$db = new DbMysql(...);
$res = $db->query('SELECT * FROM ma_table');


Conclusion : on voit ici que les arguments internes de gestion de la
base sont encapsulés dans la classe. Il n'est meme point besoin de s'en
préoccuper. L'utiliser de la classe ne sait meme pas que ca existe.

L'avantage de cette conception "tres simple", facile a maintenir
est de masquer les vilaines choses et d'offrir un minimum
d'encapsulation. C'est juste de l'encapsulation. Je ne crois pas
que cela donne de la portabilité sauf a changer la classe
d'instentiation et a redefinir des sous-classes spécialisées
fonction du type et de la version de la base de données.

CrazyCat wrote:

Frederic Rouchouze wrote:

(snip)

Ou bien dois-je utiliser la possibilité de la fonction mysql_query()
qui est la suivante : "Si link_identifier n'est pas précisé, la
dernière connexion est utilisée" ?

Je te dirais que c'est fonction de ton utilisation: si tu n'utilise
qu'une base, il n'y a aucun intérêt à t'inquiéter de la ressource de
connexion vu que tu utiliseras toujours la même.

Je dirais que c'est fonction de l'utilisation qui va être faite de ce
code. Si c'est du jetable, cf réponse ci-dessus. Si tu a un quelconque
espoir de réutilisation, fait tout de suite propre. Ca ne coûte pas
vraiment plus cher.

Si par contre tu dois utiliser des bases distinctes, dans ce cas il te
faut t'en inquiéter. Et dans ce cas, pourquoi ne pas utiliser tes
connexions en variable globales si tu en as besoin fréquemment?

Pour éviter que l'implémentation des classes concernées ne dépende de
variables globales ?

Honnêtement, je ne vois pas vraiment l'intérêt de faire de l'OO si c'est
pour mettre des globales. Bon, on peut aussi discuter de l'intérêt de
l'OO en PHP, voire de l'intérêt de l'OO tout court, mais c'est un autre
troll^Mdébat

--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"

Frederic Rouchouze wrote:

Je me pose une question philosophique à propos des ressources de connexion
(renvoyées par la fonction mysql_connect() par exemple) :

Afin de programmer "proprement", dois-je passer systématiquement en argument
à mes créateurs de classes une ressource de connexion ?

<demi-troll>
Ca dépend... Pour une classe chargée de générer un PDF à partir d'un
fichier XML, ce n'est peut-être pas nécessaire ?

Hein ? Je sors ? Bon, ok, je sors
--->[]
</demi-troll>

(snip)

Ou bien dois-je utiliser la possibilité de la fonction mysql_query() qui est
la suivante : "Si link_identifier n'est pas précisé, la dernière connexion
est utilisée" ?

Personnellement, je trouve ça très laid et très crade. Mais bon, je suis
peut-être un poil maniaque, hein ?

(snip)

Question subsidiaire : Si la réponse à la première question est "oui",
comment organiser au mieux mon passage d'argument ?

Je m'explique : je serais tenté de mettre l'argument $bdd en dernier dans la
liste et en argument facultatif, au cas où je dérive ma classe "truc" et que
je ne veuille plus utiliser de base de données pour stocker les propriétés
de cet objet.

<oo>
Dans ce cas, la solution 'propre' en OO n'est pas de dériver la classe,
mais d'extraire la partie persistance de la classe "truc", et d'utiliser
l'aggrégation/délégation:

// exemple à la con
class TrucBddPersistance
{
function TrucBddPersistance($bdd) {
$this->_bdd = $bdd;
}

function read(...) {}
function save(...) {}
function delete(...) {}
}

class Truc
{
function Truc(&$persistance)
{
$this->_$persistance =& $persistance;
...
}

function read() { return $this->_persistance->read(); }
// etc
}

$bdd=mysql_connect();
$truc = new Truc(new TrucBddPersistance($bdd));

</oo>

Maintenant, dans la pratique, cette approche n'est pas forcément la plus
appropriée en PHP.

Mais, dans ce cas, je ne peux pas utiliser le passage d'argument par
référence, qui me semble plus efficace pour transmettre ce type de donnée
(ressource).

Mmm... A moins que tu n'ai des milliers d'instances à créer, je ne pense
pas que ce soit bien grave.


--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"

bruno modulix wrote:

Si par contre tu dois utiliser des bases distinctes, dans ce cas il te
faut t'en inquiéter. Et dans ce cas, pourquoi ne pas utiliser tes
connexions en variable globales si tu en as besoin fréquemment?
Pour éviter que l'implémentation des classes concernées ne dépende de

variables globales ?

L'honorable initiateur du sujet parlait de fonctions et non pas de
classes, j'en ai déduit que c'était du procédural.

Si c'est en OO, effectivement il ne faut pas utiliser de variables
globales mais plutot utiliser (patapé si ke me trompe) des namespaces


--
Découvrez Original War: http://www.original-war.org
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.crazy-irc.net

Honnêtement, je ne vois pas vraiment l'intérêt de faire de l'OO si c'est
pour mettre des globales.

Parce que PHP4 a de gros problèmes avec les static, mettre une variable
en global est un moyen de pallier à ce défaut notament lorsqu'on a
besoin d'un singleton.

Bonjour,

Parce que PHP4 a de gros problèmes avec les static,

Jamais entendu parlé, mais j'en utilise très peu. Source de cette
information SVP ?

JG

Bonjour,

Parce que PHP4 a de gros problèmes avec les static,

Jamais entendu parlé, mais j'en utilise très peu. Source de cette
information SVP ?

http://bugs.php.net/bug.php?id 175

function &GetInstance() {
static $instance;

if(!isset($instance)) {
$instance = & new Request();
}

return $instance;
}

Cette fonction renvoie null, on est obligé d'assigner $intance par copie
et non par référence:

function &GetInstance() {
static $instance;

if(!isset($instance)) {
$instance = new Request();
}

return $instance;
}

C'est corrigé dans la Zend Engine 2, je ne sais pas si ça a été fait
pour la ZE 1, il semblerait que non vu le dernier commentaire.

static $instance;
$instance = & new Request();
Houlà, j'ai jamais créé un objet static de ma vie en PHP, donc je

comprends porquoi je n'ai jamais vu le problème.
En tous cas, bon à savoir, merci de l'info.
a++;

Si c'est en OO, effectivement il ne faut pas utiliser de variables
globales mais plutot utiliser (patapé si ke me trompe) des namespaces

Des namespaces ??? C'est à dire ?
--
Frédéric Rouchouze
mailto:fredchou@nospam.free.fr