Comment je vois le monde (eu enfin, les choses :D)

Alors, dans le cas ou on ne choisit pas l'option framework, voila comment je verrais les choses en plus ou moins détaillé lol.

Tout ceci repose entre autres sur le fait que je me soit pas mal documenté à propos du modele MVC (et ouai je fais mes devoirs :p ), et maintenant je vois un peu mieux comment ça peut se goupiller.

D'abord, pour la partie modele, ba ça c'est déjà commencé, l'idée globale reste la même, c'est just qu'il va falloir se taper toutes les autres classes, une par table quoi :D

Ensuite, les vues je fait ça en speed, paske j'y ai pas encore super mega réfléchis, mais en gros c'est le javascript qui s'en charge, il fait appel au controleur qui lui balance un resultat en AJAX (soit tout l'objet, soit juste des données précises), et aprés le javascript fait mumuse avec ce qu'il a lol.

Maintenant la question épineuse vient du controleur....
Alors la, malgrés ma documentation j'ai pas beaucoup de solutions sous la mimine, voila comment je propose de faire:
déjà, un grand point faible d'une solution de controleur trés utilisée, qui consiste en une seule page qui reçoit toutes les requetes, et les redirige ensuite vers des pages apropriés, est que cette page est trés fortement solicitée. Mais pour résoudre ce problème, on a un super pote: le javascript.
Tant qu'à faire, autant que les clients fassent eux même le boulot. En gros ça consisterait en une classe Controleur en javascript, avec une fonction requete (le nom est arbitraire hein, si ça vous plait pas on peut changer^^) appelée par les autres pages javascript qui va elle meme trier les requetes et les renvoyer vers les bonnes pages php.

Ensuite, les pages du controleur PHP instancient la classe qu'il faut, font ce qu'elles ont à faire, et retourne le résultat au controleur javascript qui retourne le resultat à la page javascript qui a appelé la methode.

Fiou, j'éspere que c'est à peu prés clair, sinon, dites le moi lol.
Et pi comme d'hab, si vous avez des avis, des opinions, des remarques, des coups de gueule, tout est bon à prendre, vous génez pa :p

Je vais te donner mon point de vue.

J'ai beaucoup pratiqué ruby on rails ces derniers temps. Il s'avère que le modèle MVC y est très très très bien mis en oeuvre, c'est ce qui fait la grande forme de ce framework. Et on pourrait appliquer ses principes en php :

Comme tu l'a dit, on a une classe modèle par entité.

Ensuite, on peut créer plusieurs controleurs. Chaque controleur comprend des méthodes (des actions). En réalité, chaque appel à une page correspond à l'appelle d'une action d'un controleur. A chaque action d'un controleur est associée une vue (ou pas, car certaines actions redirigent vers d'autres actions).

Exemple : Le controleur maisoncontroleur comprend les méthodes créer, lister, détruire, voir une maison.

Quand on fait appelle à la méthode lister, celle ci va charger la liste des maisons grâce à la classe modèle Maison, et transmet ces infos à la vue lister, qui se charge d'afficher la liste des maisons.

Quand on appelle la méthode détruire, la maison est détruire, puis on est redirigé vers la vue lister.

Quand on appelle la méthode créer, une instance de Maison vide est créée, puis la vue créer est affichée. Cette vue contient un formulaire, qui appelle la même méthode créer, en lui transmettant les informations en POST.

La méthode créer, si elle reçoit des paramètes POST, créé une nouvelle instance de maison à partir des paramètres. Puis elle tente de le sauvegarder en bd. Si la sauvegarde échoue, elle r'affiche la vue créer, en affichant le message d'erreur renvoyé par le modèle (et les paramètres restent présents dans la vue, puisque l'objet maison a été créé). Si la sauvegarde fonctionne, on est redirigé vers la page liste (ou vers la page voir maison).

Etc...

C'est compréhensible ?

Si non, n'hésitez pas à chercher des sites programmés en Ruby on rails, pour comprendre le principe. Les URL des pages sont souvent de la forme :

/nomControleur/nomAction/parametre1/parametre2 ... etc

@++

Piwaï