oups, on s'est mal compris:
ce que je propose c'est:
- un constructeur qui se connecte au serveur et sélectionne la base, via des données de config passées en global (serveur, login, pass et base)

=> tu ne passes pas ces variables en paramètre, pourquoi ?

- une méthode pour exécuter une requete

=> je ne suis pas certain de bien comprendre . Une seule méthode "requete()" ? Tu vires les methodes select(), update()... ? Dans ce cas les DAO ne servent à rien, tu ne gardes que l'abstraction à la base, ce qui me parait dommage (maintenance, répartition des tâches, ...).

pour le mapping objet relationnel, c'est une architecture qui fait correspondre objet <=> table (link: http://www.dotnetguru.org/articles/Pers ... apping.htm )

=>Edit : Ajouter des "ValueObject" avec des méthodes utilitaires que tu proposes comme "chargerAvecPOST()", "chargerAvecGET()", etc...

a+
david

oups, on s'est mal compris:
ce que je propose c'est:
- un constructeur qui se connecte au serveur et sélectionne la base, via des données de config passées en global (serveur, login, pass et base)

=> tu ne passes pas ces variables en paramètre, pourquoi ?

car dans tous les projets sur lesquels je travaille il n'y a qu'une seule base d'attaquée, et que c'est toujours la même. Donc soit on écrit ça en parametre à chaque création d'objet, soit on mets ça à l'extérieur. je mets tout ça dans un seul et unique fichier config, c'est simple à gérer car centralisé.

- une méthode pour exécuter une requete

=> je ne suis pas certain de bien comprendre . Une seule méthode "requete()" ? Tu vires les methodes select(), update()... ? Dans ce cas les DAO ne servent à rien, tu ne gardes que l'abstraction à la base, ce qui me parait dommage (maintenance, répartition des tâches, ...).

L'abstraction à la base est suffisante pour le mapping objet relationnel, je ne vois pas vraiment l'utilité du DAO.

pour le mapping objet relationnel, c'est une architecture qui fait correspondre objet <=> table (link: http://www.dotnetguru.org/articles/Pers ... apping.htm )

=>Je suis pour à terme ajouter des "ValueObject" avec des méthodes utilitaires que tu proposes comme "chargerAvecPOST()", "chargerAvecGET()", etc... mais je pense qu'il vaut mieux voir cela après, il n'a pas de dépendance avec les DAO...
[/quote]

Si tu as de la doc sur les DAO, je suis preneur.

A+

Sur les DAO :
http://www.phpindex.com/articles/articl ... lement=459 (suivre le lien, mais je te mets cette page car il y a un commentaire intéressant)
http://java.sun.com/blueprints/corej2ee ... bject.html
http://www.phppatterns.com/index.php/ar ... iew/25/1/1 (faut que je le relise tiens !)

J'ai lu un article intéressant dans le magazine phpsolutions n°2.

L'abstraction à la base est suffisante pour le mapping objet relationnel, je ne vois pas vraiment l'utilité du DAO.

Pour moi voici les avantages :
- le code d'accès aux données est délégué à un objet dont c'est la seule tâche (répartition des responsabilités).
- facilite la maintenance
- une requête est écrite une seule fois et peut-être appelée partout dans le code.
- possibilié de générer ces objets automatiquement (au moins le tronc commun)
- possibilité dans une équipe de répartir le travail
- facilite un changement dans la base

a+
daoud

je n'ai pas tout lu, mais on dirait qu'on poursuit les mêmes buts

Dans la série les milles et une façons d'implémenter la pattern DAO :
http://www.onlamp.com/pub/a/php/2004/08 ... tml?page=1


daoud
(qui est toujours preneur de vos remarques )

Dans la série les milles et une façons d'implémenter la pattern DAO :
http://www.onlamp.com/pub/a/php/2004/08 ... tml?page=1


daoud
(qui est toujours preneur de vos remarques )

c'est grosso modo ce que j'utilise.
j'avais fait un code qui dégrossissait le développement:
http://toys80.free.fr/doclass/

(mais j'ai paumé le mode d'emploi )

A+

Pascal

Super
Je suis en train de regarder.... Comment gères-tu les jointures ?

a+
daoud

Super
Je suis en train de regarder.... Comment gères-tu les jointures ?

ce n'est pas géré. Pour ça, il faudrait un éditeur web graphique (je regarde du coté de JS pour faire ça, ça a l'air possible mais avec du boulot! ) ou modifier le code généré à la main .

A+

Pascal

En tous cas, le débat est bien lancé

J'ai quand même relevé un truc dans ton système pascaltje : les méthodes UPDATE intègrent les clés primaires: pas top. Il doit bien y avoir moyen d'identifier les clés primaires dans les tables pour ne pas les modifier avec un UPDATE. Sinon, il faudrait se taper toutes les classes et les corriger à la main

En tous cas, le débat est bien lancé

J'ai quand même relevé un truc dans ton système pascaltje : les méthodes UPDATE intègrent les clés primaires: pas top. Il doit bien y avoir moyen d'identifier les clés primaires dans les tables pour ne pas les modifier avec un UPDATE. Sinon, il faudrait se taper toutes les classes et les corriger à la main

exact

d'ailleurs je les détecte sur cette page les clés primaires:
http://toys80.free.fr/seebdd/voirsabase.php
(javascript pas forcément hyper portable)
(d ailleurs j'y travaille aux MCD version web, héhé!)

après faut coder avec les muscles ( = "if" partout... )

A+

Pascal

En fait pour les jointures je me pose la question suivante.
Avec une table livre et une table auteur : Pour récupérer un livre avec le nom de l'auteur dans ton système il faut deux requêtes non ?
C'est le problème de mettre les données dans des objets. Tu dois avoir les deux objets dispos dans ce cas, livre et auteur, chargés par deux requêtes select distinctes. $livre->select("SELECT * FROM Livre WHERE libelle = "toto"); puis $auteur->select("SELECT * FROM auteur WHERE idAuteur = " . $livre->idAuteur);
Alors qu'une requête avec jointure peut te ramener tous les champs dans un tableau. Quelle est la solution ? passer un objet auteur en paramètre d'une méthode et faire $livre->selectAvecAuteur("SELECT * FROM Livre l, Auteur a WHERE l.idAuteur = a.idAuteur AND libelle="toto"); et mettre les valeurs retournées dans les objets ?
Ai-je mal compris ?

a+
daoud

re-exact

la classe permet de dégrossir le boulot pour utilisation bête et méchante d'une base;
si on veut accéder aussi à l'auteur d'un livre, il faut modéliser ça au niveau objet (UML rules) et inclure la jointure dans la classe (à mon avis).

peut être que d'autre personnes pourraient nous en parler?

A+

Pascal

A mon avis, dans ce cas on tombe dans les outils de mapping objet relationnel qui sont des usines à gaz, comme propel pour php, hibernate pour Java. Ca rejoint le post que j'ai lancé en parallèle (je l'ai posté dans le forum php comme un con)... Si on pouvait avoir un avis d'un expert en la matière

Pour des "petites" appli php, on peut se contenter d'un mini-framework sans mapping, non ?

a+
daoud

Je suis plutôt d'accord. Pour une petite application, je ne pense pas que ça vaut le coup de se lancer dans Propel qui, en plus, nécessite Creole et Phing...

Jusqu'à maintenant, j'écrivais une classe avec les méthodes classiques (select, insert, update, delete) pour chaque table de ma base de données. C'est vite lassant, d'où mon intérêt à la lecture de la méthode proposée par daoud.

Je ne suis pas sûr d'avoir bien compris le principe et j'aimerais savoir si cette méthode permet d'obtenir un tableau d'objets dans le cas d'un select. Le fait que $arrayChamp soit dans la Dao me paraît bizarre. J'ai l'habitude de faire :

<?php
$result = mysql_query("SELECT * FROM table");

$i=0;
while ($row = mysql_fetch_row($result) ) {
    $objets[$i] = new Objet();
    $objets[$i]->setChamp1($row["champ1"]);
    $objets[$i]->setChamp2($row["champ2"]);
    ...		
    $i++;  
}
return $objets;
?>

Est-ce qu'on peut obtenir quelque chose d'équivalent avec cette méthode ? Merci d'avance.