Reprise du message précédent :

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.

C'est exactement ce que je disais. Quiconque ne fait pas ça dans son modèle n'a pas une réelle abstraction entre le modèle et le reste. Ca n'a rien à voir avec une couche à part, c'est le modèle. Le modèle n'est pas seulement l'accès à la base de données.

J'avais raté ton edit.
...et non, non et non.

(1) Modèle
(2) Contrôleur
(3) Vue

C'est tout. Que ta vue sorte du html, du pdf ou un document word tout le monde s'en branle, c'est interne à la vue.
Que ton modèle fournisse une interface publique qui sert en interne de couche d'abstraction, c'est normal et tout le monde s'en fout aussi.

Ce que je veux dire, c'est que pour un même contrôleur tu peut avoir plusieurs vue différentes.
 
Rien n'interdit que pour l'action "listeCommandes" du contrôleur "client" tu ai plusieurs vue différentes.
Cas typique une vue "Web" et une vue "Mobile" par exemple.
 
C'est certes au front controller de géré ça, mais c'était pour illustrer la possibilité.

 
 
Il faut raisonner en termes de couches...tu te réfères à un type d'implémentation particulier, là, ça complique la discussion.

mhhh je vois que ca suscite le debat, ce n'etait peut etre pas une question si stupide...
 
ce que je comprends de vos ecrits.  
 
le modele , c'est bien le traitement .
par traitement la plupart d'entre vous auront compris , je voulais dire les operations en dehors de l'acces aux données.  
par exemple dans le bete cas d'une zone membre, le modele contiendrait les fonctions ajouter_user,delete_user ect.  
par traitement j'entends qu'il y a avant d'acceder a la base de données , un certain nb d'operations a effectuer, comme de verifications  des champs fournis, verification d'existence du membre (pour ne pas l'ecraser ) etc.  
 
pour moi je comprends donc , non pas 3 mais 4 couches :  
M V C et acces a la bdd . (je tiens a separer l'acces aux données car mon projet actuel pourra travailler soit sur xml , soit sur sql. je pense que dans ce cas la , il est intelligent de sortir l'acces aux données du modele.  
 
etes vous d'accord?  
 
grand merci.
 
ps;  
pour preciser l'objet de mon message et l'incomprehension initiale:  
tous les tutos que j'ai vu (devellopez, sdz etc, ) sur le mvc parlent de la gestion d'un espace membre , evidemment comme il s'agit d'un tuto et non pas de tp, les codes sont simplifiés a l'extreme et surtout toutes les fonctions ne sont pas implémentées.  
 
du coup dans ces tutos les seules choses que l'on voit dans le modele ,ce sont en gros des requetes sql.  
d'ou ma confusion.

Ça fait aussi partie du modèle. Il peux proposer des fonctions genre validate_user & check_user.

 
haaaa attention  
 
la tu me reconfuses....  
 
je n'aurai pas dit ca fait partie du modele mais C'EST le modele

Ca dépends quelles validations.
 
Si c'est des validation d'intégrité oui, mais si c'est une validation type champs obligatoire, champs nécessaires si tel radio est sélectionnée, ça non c'est au form de le faire (donc au niveau du contrôleur).
 
Avec  Zend Framework on ce genre de template assez couramment :

 
EDIT :
Approche Service :

 
Non. L'accès aux données fait toujours partie de la couche Modèle. Cette dernière contiendra une "sous-couche" d'abstraction / d'interface publique (la couche "service" de MEI), et en-dessous autant de "sous-couches" d'accès aux sources de données que tu veux.

Effectivement
 
 

Je dirais que pour le type "champ obligatoire", ça fait aussi partie du modèle, car étant de l'intégrité aussi . Enfin dépend aussi du champ
 
Genre pour un formulaire d'inscription avec login & pass. Le modèle veut un nom d'utilisateur et un mot de passe (avec des contraintes potentielles genre taille min & max, etc.). Le formulaire lui voudra un deuxième mot de passe de confirmation égal au premier.
 
On aurait donc plusieurs "étages" de validations : le premier niveau formulaire, le deuxième niveau modèle.

 
Non, le premier c'est dans la vue.

C'est ce que j'entendais par formulaire en fait

 
Alors t'en as deux à ton niveau "formulaire". Un coté client, un coté serveur.

http://thedailywtf.com/Articles/Th [...] aspx#PPic2
 

Wrong thread

oui.

 
Non, ça c'est TON cas particulier. Mais en MVC rien n'est défini. On peux avoir des modèles qui n'inclus pas la persistance, et n'en sont même pas conscient.
Exemple lorsque l'on utilise un ORM.
 
Dans JDO par exemple (certes c'est du Java), on écrit le modèle de façons standard, getter/setters/méthodes. Après c'est un fichier XML de définition du mapping objet-relationnel et une moulinette post-compilation qui modifie le byte-code de l'objet.
 
Mais en pratique dans le code on a ce qu'ils appelles un PersistenceManager et qui lui gérera les objets persistants.

 
Ce code serait donc dans le contrôleur typiquement, et dans un cas la logique est dans le modèle (où un classe mère du modèle), dans l'autre dans une classe présente dans la library, et ce n'est même qu'une classe technique comme un autre finalement.

En MVC tout fait partie de M, V ou C, point barre. Arrêtez d'inventer des couches qui n'existent pas.
Si tu as de la persistance, c'est dans le modèle. C'est tout.
Qu'il y ait de l'abstraction dans chaque couche c'est très possible et même probablement souhaitable. Mais ça n'en fait pas un PSMFCCVHPX. C'est toujours M, V, et C, ou tu ne fais plus du MVC.

This.

MVC n'est pas une design pattern en soit, elle définit juste l'organisation générale d'un point de vue assez haut. Libre à tout d'implémenter M, V ou C différemment. Un modèle peut ainsi être splitté en plusieurs composants.

Pour reprendre l'exemple de la validation de données, on pourrait avoir une classe model_user qui propose une méthode check_user. Mais on pourrait très bien aussi carrément avoir un objet à part entière qui ferait ça, genre user_checker. Ce dernier ferait conceptuellement partie du modèle, même s'il est séparé de l'objet assurant la persistance.

Une classe purement technique type parsing de XML tu met ça dans le modèle toi ?
 
Pour moi c'est simplement une classe technique => Library, et donc tout n'est pas obligatoirement MVC.

 
voila .  
la on commence a toucher le noeud de ma question ....

 
C'est une bibliothèque complètement externe à l'application proprement dite, ça.  
Sinon tu peux aussi essayer de faire rentrer les fonctions natives du langage dans la boite tant que t'y es...

Ah donc pour toi l'application c'est les vues/contrôleurs/modèles, mais pas le framework autour qui fait tourner tout ça ?
Donc en gros tout est MVC sauf ce qui ne l'ai pas...
 

Le framework ne fait pas partie de ton appli. C'est un pré-requis à son bon fonctionnement, comme n'importe-quelle lib que tu utilises.
Si tu codes pour windows, non, l'API win32 entière ne fait pas partie de ton appli.

...Et ta manière de mettre Vue/Controleur/Modèle au pluriel m'horripile - et caractérise très bien ta façon de considérer uniquement une certaine implémentation du truc.

Si tu ne comprends déjà pas la distinction entre ce qui est ton appli et ce qui fait partie d'une lib externe on risque pas de se comprendre, hein...

...et avant que tu demandes, non, l'ORM ne fait pas partie de ton appli non plus.
Tout ce que tu fais avec, si. Et c'est dans le Modèle.

Quand tu développes une application, tu te concentes seulement sur ce qui concerne l'application. Le framework est là pour t'aider. Si ton application fait du MVC, ton framework n'a pas à ramener sa fraise dans ce MVC, et pire si c'est une classe Utilitaire de transformation de XML par exemple, il n'y a pas à la foutre dans le MVC

La persistance, c'est du technique que ce soit base de données ou fichiers XML, donc oui, je le foutrais dans le modèle. Pourquoi traiterais-tu deux solutions au même problème de façon différente?

Si sa classe ne fait que du parsing de xml, c'est une simple lib. Qui peut aussi bien être utilisée dans le modèle qu'ailleurs.

J'ai dans certaines méthodes un bout de script qui vérifie si l'user est admin pour qu'il puisse accéder à certaines pages. Typiquement, j'ai une classe news, une user, etc, et les fonctions admin sont aussi dans ces mêmes classes, mais sont protégées par ce petit bout de code.
 
Ce que j'aimerai faire, c'est foutre ces 3 lignes dans une fonction, mais je ne sais pas où ranger cette fonction

Si t'as une classe user, pourquoi pas tout simplement une méthode style isAdmin() dedans?

Je me suis mal exprimé : "qui vérifie s'il est admin, et si ce n'est pas le cas il est redirigé".

En gros :

if (!$this->user->is_admin())
    redirect('home');

Tu peux par exemple mettre ça dans une fonction qui sera chargée à l'init des contrôleurs qui ne servent que pour la partie admin?

 
Il n'y a pas de contrôleurs qui ne servent que pour la partie admin.

Alors dans tous tes contrôleurs...si possible dans la classe abstraite de laquelle ils dérivent...

Il a pas trop le choix, il faut que chaque action qui le nécessite fasse d'elle même la vérification d'ACL.
 
En Zend Framework ça donne un truc comme ça :

 
On peux aussi utiliser un plug-in de contrôleur pour faire des tests plus généralistes pour un contrôleur/module donné.
Mais dès qu'on est au cas par cas on a pas vraiment le choix.

 
oué enfin tu le mets au moins dans une méthode de classe...qui peut être remontée dans ne classe mère si elle existe, ce qui serait déjà nettement mieux. Histoire de pas avoir à reprendre tout ton code le jour où tu changes d'outil pour gérer les acl...

dans symfony, toutes les actions commencent par les tests d'authorisation / de format reçu /...  
C'est pas super contraignant et ça simplifie vraiment la lecture

C'est obligatoire?

non
mais la classe d'action construite par défaut est comme ça, et encore une fois, je trouve pratique d'avoir la partie authorisation bien visible

de toute façon, la gestion des droits est souvent problématique a placer dans le mvc, avec des bouts qui sont dans le controleur de d'autres dans la vue