Voici le décor :
 
j'ai les deux classes suivantes :
 
- base (qui gère la base de données : (de)connexion, acces a ceraines donnees, ...)
- utilisateur (creation d'utilisateurs, methodes qui generent des structures qui dependent de l'utilisateur et autres choses)
 
dans l'utilisation que je fais du coté objet de php, je ne fais pas beaucoup d'instanciations et les objets ne sont pas tres liés entre eux comme une application rigide de la poo le voudrait. En fait je me sers plus de l'approche objet pour definir des structures de donnees rigides et clarifier le code (soucis de compréhension donc).
 
Voila le décor. Maintenant lorsque j'instancie un utilisateur, je dois pouvoir l'enregistrer dans la base via une methode ajouter utilisateur. Pour l'ajout a proprement parler, pas de probleme je sais faire. Mais je me suis retrouvé devant un probleme pour choisir dans quelle classe je mettais cette methode.  
 
Voila les deux possiblités :
 
- methode dans la classe base
function ajouterUtilisateur($utilisateur)
 
- methode dans la classe utilisateur
function ajouter($base)
 
Le resultat est le meme evidement mais il doit bien y avoir qqchose plus de logique dans ces 2 solutions...
 
Si vous avez un grain de sel a mettre...
 

je mettrai dans la classe base qui doit être un singleton

Moi, je le mettrai coté base, car c'est elle qui sait quels champs doivent etre remplis, c'est elle qui sait ou elle en est dans ses index (s'il y en a), de plus, si d'autres appli utilisent la même base, ça ne pose pas de problème de compatibilité, et évite des redondances dans le code, bref, mieux vaut, à mon avis, dans ce cas, faire en sorte que l'unité contenant le traitement de la base sache gérer la base en entier.
Ca évite d'avoir des bout de codes qui manipulent la base un peu partout dans tes unités ... valà, bref, j'espère que tu m'auras compris ...    

je le mettrais dans la classe utilisateur ( semantique comme logique)
 
d'ailleurs, tu ne vas pas mettre tout les objets qui se rapporte à une connexion bdd dans ta classe base (sinon aucun interet de penser objet)  
 
de plus, tu le dis toi même :
je me sers plus de l'approche objet pour definir des structures de donnees rigides et clarifier le code (soucis de compréhension donc).
 
( voila pour mon avis     )

 
En fait, je pense pas qu'il comptait mettre l'objet "personne" dans son unité qui gère la base, mais juste la fonction qui permet de l'enregistrer dedans , d'ailleurs, il a lui-même dit qu'il avait déjà une classe utilisateur ...
Enfin je m'ai peut-etre trompé dans l'interprètation de son énoncé, mais il me semble qu'il se demandait juste à quel endroit il devait implémenter le code qui inscrit les données dans sa base. De ce point de vue là, je pense que c'est plutôt du côté de la classe base que cela se passe, nan ?    

C'est chaud tous les avis se defendent...
 
simogeo n'a pas tort du tout quand il dit que je ne vais pas mettre tout le code qui modifie/accede la base dans la classe de cette derniere.  
Je ne sais pas pourquoi (c'est vraiment un sentiment perso), je prefere mettre les methodes de modification de la base dans la classe base.
Par contre toutes les methodes d'acces aux donnees pour creer des structures d'affichage sont dans leurs classes respectives.
 
En tout cas merci bcp pour vos avis car c'est vraiment pas evident comme choix. Je pense qd meme que ca vaut le coup d'y reflechir meme si le resultat n'influe pas beaucoup.

personnellement, je mettrais cette méthode dans la classe utilisateur puisqu'elle traite les données concernant l'utilisateur. Cette méthode contient la création de la requête et l'appel d'une méthode de l'objet base (méthode insert() par ex).
la classe base doit contenir les paramètres de conexion et les méthodes de dialogue avec la base mais sans être lièe au contenu des tables de la base.
 
c'est comme ça que je vois les choses, mais votre avis là-dessus m'intéresse!

Toutes mes modifications dans la table sont faite par des procedures stockees oracle. J'y fais appel dans une requete php tres simple :
 
$req = "begin PROCEDURE(:param1, aram2,...) ; end ;"
 
le panel de procedure de modification de la base est le suivant :
 
- ajout, modification, suppression d'utilisateur
- ajout, modification, suppression de groupe
- ajout, modification, suppression de pages
- affectation / desaffectation  d'utilisateur à un groupe
- autorisation/retrait de droit d'acces a une page pour un groupe
- autorisation/retrait de droit d'admin sur une page pour un groupe
- modification de preferences utilisateur d'affichage pour une page
 
Pour que vous compreniez bien ce que je voulais dire quand je disais que mon orientation objet n'etait pas tres standard, un exemple :  
 
J'utilise des objets utilisateur que j'instancie grace a un acces a la base. Dans ce genre de cas (pour reconforter simogeo qui croit que je met tout dans la classe base), c'est le constructeur de la classe utilisateur qui prend la base en parametre et qui me sors donc un utilisateur de la base.
 
Je fais de meme pour les groupes et les pages.
 
Voila

ajouter un utilisateur ne concerne pas la classe Utilisateur mais plutot une classe GestionUtilisateurs, ce qui est très différent