Reprise du message précédent :
a bon, pourtant mon model est tout à fait indépendant du reste.
je suis partis du principe d'un CRUD sur chaque table pour le multiActionControler
et j'ai un model (accès à la base données) qui pour chaque multiActionControler et action établie un requete SQL.
 
Fonctionnement de mon contrôleur :
Le controleur ce charge d'analyser l'URL, de définir une route par défaut (si nécessaire) charger le bon multiActionControler, vérifier la présence de la méthode demander et si elle existe la lance (si elle n'est pas trouvé chargement de la méthode par défaut).
Le controleur instancie aussi une classe de retour appelé ModelAndView, qui contient les données en provenance du model (mais qui est initialisé par le multiActionControler) et la vue à charger qui a été initialisé par le multiActionControler.
La méthode render du controleur analyse la classe ModelAndView et génère la sortie.
 
voila pour le fonctionnement.

 
Euh mais ton multiActionControler tu le mets dans le modèle?

j'ai pas écris ça, j'ai dis que le multiActionControler appel le model
le model retourne les données au multiActionControler qui les fait passer a la classe ModelAndView.

surtout pas, ce sont bien 2 choses complètement différentes

...donc c'est bien ce que je disais : tes "multiActionControler", qui font partie de la couche "Controller", sont très liés à une certaine représentation du modèle - tu en as grosso-merdo un par table...
 
Après ton histoire de ModelAndView j'ai du mal, aussi. Soit je comprends rien, soit ta séparation des couches est vraiment hasardeuse.

oui, est-ce mal :??
ensuite j'étais partis sur une autre version, avec cette fois une classe abstraite commune à toutes les autres classes,  
 

 
je l'utilise pour "stocker" les données, je ne sais pas comment faire autrement

 
Niveau séparation des couches c'est mal barré - tu peux difficilement toucher à l'un de manière transparente pour l'autre, avec ce genre de système...ce qui ne va pas dans le sens du MVC.
 

 
Pourtant ça me parait raisonnablement simple en théorie : le contrôleur, une fois qu'il a récupéré les données dont la vue a besoin, les transmet à la vue (après les avoir éventuellement transformées dans le format attendu), et lui demande de s'afficher.

Comment passe t-on les données du model au controleur ? car les actions sont gérer ailleurs. pour ma part c'est donc mon multiActionControler qui interroge le model.
 
petite explication supplémentaire : ce que j'appelle controleur, c'est la classe qui appel les multiActionControler et nettoie l'URL

Ce que tu appelles contrôleur pourrait tout aussi bien faire partie de la vue, donc (en théorie l'url en fait partie - tout ce que le controleur devrait connaitre c'est une représentation abstraite de l'action que vient d'effectuer l'utilisateur).
 
Quand je parle de contrôleur c'est de la couche dans son ensemble, sans entrer dans les détails d'implémentation.
Le contrôleur est celui qui instancie le modèle, je ne comprends donc pas vraiment la question, pour le coup.

 
C'est le controlleur qui interroge le modèle. Il fait l'entremetteur entre le modèle et la vue quoi.
 
Sachant qu'il est souvent divisé en Front Controller (qui checke l'URL, fait tout le boulot ingrat et redirige vers la bonne action) et Action Controllers (qui font le vrai taf : interroger les modèles et transmettre les infos aux vues)

d'accord alors moi non plus, car pour moi le contrôleur, il controle l'arrivé de l'internaute et appel l'action si elle existe.
Pour moi c'est l'action qui appel l'accès à la base de données (model).
 
j'ai lu beaucoup d'article dont celui-ci : http://julien-pauli.developpez.com [...] ontroleur/
puis j'ai un gros mix de plusieurs technique.

L'action fait partie de la couche Controller (Action Controller)

 
c'est exactement ça
contrôleur pour moi c'est le frontControleur
Action Controllers est mon MultiActionControleur car j'ai regroupé ici plusieurs action en rapport à une même table.

C'est ça que tu fail.

Il peut se trouver qu'un groupes Actions soit relatifs à un même modèle (ex: Photo), mais ça ne doit en aucun cas être un principe fondateur. Tu peux très bien avoir par ex un ActionController "Home" qui va appeler plein de modèles différents (les nouveaux users, les derniers articles, les news) sans être spécialement lié à l'un d'eux.

Un ActionController et une action pour moi c'est pareil, après tu t'organises comme tu veux niveau sémantique (par ex dans Symfony ça s'appelle juste "module" ), mais en gros dans ton cas les "ActionController" ne devraient être que des tiroirs pour regrouper tes actions comme bon te semble.

OK, c'est pour ça que l'on appel MultiActionControleur, donc ça voudrais dire que c'est elle qui doit appeler et lancer ma vu et non mon front contrôleur !!
car pour l'instant c'est mon front contrôleur qui traite ma vue. d'ou La méthode render du contrôleur qui analyse la classe ModelAndView et génère la sortie.

 
OK donc j'ai un problème dans mon analyse.
il faut que je reprenne tous.
En faite j'étais parti sur un simple CRUD (il y a 3 ans) puis l'application a évolué entre temps mais je n'ai pas eu le temps de faire mieux, donc j'étais partis sur ça et ensuite je n'ai juste fais que d'apporter des patchs dessus pour ajouter des fonctionnalités.

alors, il faudrait que je commence par quoi ?
définir les actions possible et énumérer les données utile pour chacune d'elle?

donc si j'ai bien compris j'ai le
- FrontController qui traite l'URL, vérifie la présence de l'action et la lance,
- les actions utilisateurs qui vérifie les paramètres, va chercher les données, choisi la vue et lance une classe qui génère la vue.
 
ensuite, les actions utilisateurs sont mon "métier"
et à part il y a le modèle qui s'occupe des requete SQL.
 
Suis-je bien parti comme ça
je cherche à faire une application modulaire et facile à maintenir et à faire évoluer.

Si je lis bien ton poste il y a dans ton archi des trucs que tu ne classes ni dans le modèle, ni dans le controleur, ni dans la vue...je comprends mal?

j'ai voulu séparer le traitement des données  et les requêtes SQL, même si elle sont extrêmement lié.
devrais-je les mettre dans la même classe pour plus de clarté
 

 
ça fait partie de la vue, mais j'ai un template, la vue choisit est juste le morceau que l'utilisateur demande.

J'ai l'impression que tu confonds un peu les couches (théorie) et leurs implémentations concrètes...
 
Rien ne t'empêche en effet (et c'est même plutôt recommandé) d'avoir plusieurs niveaux dans chaque couche! Par exemple dans le modèle tu vas avoir une couche d'accès à la base de données, mais tu ne vas probablement pas l'appeler directement à-partir de ton controleur!
Tu vas plutôt avoir une couche supplémentaire dans le modèle, qui va servir d'interface entre les deux tout en implémentant les règles métier.
 
Coté vue idem, tu peux avoir un moteur de templates si tu veux, mais tu vas avoir une couche d'interfaçage entre cette implémentation très concrète et ton controleur.

En cours mon prof m'a dit que normalement dans un modèle MVC le controlleur ne sert qu'à transmettre les données à la vue, et que toute la partie logique doit se faire dans le modèle, hors dans mon entreprise on utilise cakephp, et toute la logique se fait tout le temps dans le controller, et la plupart du temps les modèles sont quasiment vides. Et je pense que c'est comme ça que tout le monde utilise cakephp ou presque... Du coup je me demande si c'est propre à la communauté php d'utiliser le controller de cette façon ou si les développeurs java ou autre font pareil par exemple?

 
C'est souvent comme ça que font les gens avec les frameworks php, de ce que j'ai vu. Mais c'est des mauvaises pratiques.

Voilà, mais j'ai l'impression que paradoxalement si tu veux appliquer la "bonne" pratique, tu te retrouves en marge par rapport à tes collègues qui font différemment, et c'est contre-productif au final. (même dans le tutoriel du blog sur cakephp, que tous les débutants font avant de commencer à découvrir le framework, il me semble bien qu'ils mettent leur logique dans le controller)

 
Je trouve que la plupart des frameworks php "lights" genre cakephp ou codeigniter sont destinés à des projets pas trop gros, du coup c'est moins grave si la séparation des couches est plus floue (pour les validations par exemple). Ce qui est moins le cas avec les grosses machines comme syfony ou rails/django

je sais pas si on peut dire que cakephp est "light", c'est plus lourd que codeigniter il me semble, au travail on est plusieurs sur un unique projet, assez conséquent, et on utilise cakephp. A moins que tu fasses allusion a la forte présence "d'automagic" quand tu dis "light" ?

Au taff toute la validation des données propres à la db se faisait dans les modèles, mais on avait un framework maison.

Ça dépends des framework, mais souvent t'as une validation fonctionnelles (genre si c'est une contact téléphone, on doit préciser si c'est un perso ou un pro), et une validations plus d'intégrité, à savoir vérifier que ce qu'on va envoyer à la DB est bien dans le bon format (les booléen ou date par ex. suivant comment on décidé de les mettre en BDD).

 
Voilà, exactement.

salut  
je me debrouille pas trop mal en php .
j'essaie d'appliquer le modele mvc mais j'ai un point sensible que je n'arrive pas a resoudre. Je ne cache pas que je suis loin de saisir la moitié des discussions de ce thread mais si je poste ailleurs je vais me faire modaliser par un engueuloir.  
 
bref , la vue c'est clair et simple .  
le controller aussi , a peu pres .  
 
de ce que j'ai compris le controller ne sert qu'a repondre aux actions de l'utilisateur .  
il reste donc le modele . dans quasi tous les tutos que j'ai vu , le modele c'est l'acces aux données .
 
jai du mal a comprendre dans ce principe ou se place le TRAITEMENT des données . dans le modele ? une autre couche d'abstraction?  
 
merci pour vos conseils.

Qu'est-ce que t'appelles exactement traitement des données ?

 
Ta question est un peu floue, mais la réponse est probablement le modèle, oui.

Normalement modèle = objet metier + traitements + règles de gestion.
La persistance ça peut être une autre couche, ou dedans.
 
Après y'a aussi une approche avec une couche de service où le contrôleur attaque la couche service qui offre donc des services type "liste les commandes du client machin".
Ca encapsule un peu plus, et après si on veut réaliser un web service, lui aussi attaquera cette couche.
 
Je l'ai jamais mis en oeuvre, c'est beaucoup de code partout, mais ça semble très simple a maintenir par la suite.

C'est qu'une vue, ça, la "liste des commandes du client machin"...je vois pas ce que tu appelles la "couche service", dans l'histoire...?

Le modèle, c'est l'accès aux données, la validation, le traitement, la sauvegarde.

Non la vue ne fait que l'affichage.
La couche service s'occupe des échanges d'informations et des traitements.
 
EDIT : on peut imaginer ça :
 
(1) Modèle
(2) Service
(3-a) Contrôleur
(4-a-a) Vue "HTML"
(4-a-b) Vue "XML"
(4-a-c) Vue "PDF"
(3-b) Web Service
 
Ça permet de factoriser au mieux le code. I.e. tu veux permettre une impression PDF de la liste des commandes du client, pas de soucis, suffit de faire une vue "PDF" qui formatera les données différemment.

mais concretement une ouche service ba présenter les données  sous un format  d'echange ( soap par exemple ) , c'est donc une vue + un controleur

 
Ce que je veux dire, c'est que "liste des commandes du client machin" ce n'est qu'une manière de présenter une partie des données...ça m'aide pas du tout à comprendre ce que tu veux dire par "couche service"
 

 
Rien compris. Ou alors c'est juste l'interface publique de ta couche modèle, par opposition à une couche modèle "brute" qui ne contient qu'un orm-like?

si c'est que ça, ce n'est pas une couche à part, c'est seulement une partie du modèle qui devrait exister partout.

Liens vers un PPT qui explique un peu :
http://www.slideshare.net/weieroph [...] shop-dpc09
 
Par contre, c'est TRES orienté Zend Framework, et ça reste, même pour du Zend Framework, pas forcement l'utilisation la plus courante en fait (enfin par rapport à la doc. ou les livres sur le Zend Framework on va dire).

Webservice, c'est aussi du MVC, c'est juste que le dialogue est un peu différent. Et vire ton point (2). Les mécanismes de persistance des données sont intégrés au modèle.