Reprise du message précédent :
avoir besoin d'une seule instance ca n'a rien a voir avec un singleton tu peux partager l'instance entre tes objets sans avoir de singleton c'est plus simple et plus propre

et tu peux pas specialiser un singleton (because constructeur en private) donc deja rien que ca ca devrait faire reflechir avant d'utiliser un singleton

Ouais enfin on peut très bien mettre le constructeur en protected hein

ouais du coup splus un singleton quoi

T'es sérieux quand tu racontes une connerie pareille?

Singleton : Garantit qu'une classe n'a qu'une seule instance et fournit un point d'accès de type global à cette classe. Source : GOF.
On ne peut plus clair, non ?
 
Maintenant, Souk, il y a certainement bien des manières de garantir l'unicité d'une instance, et Singleton en est une. Je trouve celle-ci très propre, même si singleton est décrié comme étant un anti-pattern par excellence. Mais c'est un autre débat...
 
Qu'entends tu par "spécialiser un singleton" ?
 
Le constructeur peut être ce que vous voulez (C'est plus clean de le rendre private ou protected). Par convention, on ne construit pas un Singleton, il doit se construire lui-même. On accede par un getInstance() par exemple. Il s'instancit lui-même.

 
bah ouais, a partir du moment ou le constructeur est protected, y a plus rien qui garantit qu'il n'y a qu'une seule instance, vu que les classes filles peuvent l'instancier comme elles le veulent donc par definition du GOF sus-cite gentiment par notre ami, ben splus un singleton
 
et toi, t'as d'autres conneries d'expert a etaler ?

Il me semble pourtant bien qu'il y a dans le GOF un exemple de singleton subclassé

D'un autre coté j'ai du mal à voir dans quel cas on pourrait vouloir ça...un singleton subclassé pourquoi pas, mais à priori ce sera une classe abstraite, non?
Auquel cas constructeur protected et basta...

pour un vrai singleton ouais, aucun besoin de spécialiser, mais le probleme, c'est que le singleton est utilisé la plupart du temps pour pouvoir localiser un objet rapidement via une methode statique : MonBeauSingletonReluisant.getInstance() avec MonBeauSingletonReluisant etant un objet tout ce qu'il y a de plus normal, genre une DataSource, une Configuration et autres... et ces objets la, ca a un sens de les specialiser

 

Oui, mais est-ce que tu ne vas pas te servir que de la version spécialisée "finale"?

Je récidive : Pourquoi vouloir spécialiser un singleton ?
 
A mon sens, un Singleton est déjà un objet spécialisé. Vous ne seriez pas entrain de mélanger le pattern et son implémentation ?

'fait, en rangeant mes favoris j'ai retrouvé ça sur les singletons (et les DPs du GoF en général)
 
Vous noterez qu'il confirme la possibilité d'hériter d'un singleton, bien que celle ci dépende des implémentations

Je me permets de up ce topic pour une question toute bête (étonnant non ?   ), et plus pragmatique que conceptuel
 
Imaginons que je veuille faire un traitement sur un grand nombre de données, assez pour saturer la mémoire du serveur.
 
Quand je mélange la view et le model, je peux balancer une requête SQL, faire une boucle sur le résultat, qui va effectuer à chaque fois l'action voulue (par exemple afficher en html la ligne récupérée dans la table de la base). Ceci sans charger la mémoire vive.
 
Si je veux séparer la view et le model, le model va faire la requête SQL et charger les résultats dans un tableau, que la view va récupérer pour affichage (jusque là j'ai à peu près suivi ou j'ai déjà décrocher ?).  
 
Mais alors, comment faire si le nombre de données récupérées est telle que les charger toutes dans un tableau remplit la mémoire du serveur ? Vous récupérez les résultats petites quantitées par petites quantitées, en refaisant une requête SQL à chaque fois, ou un truc du genre ?

Djebel > tu fais passer des évènements ne représentant le chargement d'un petite partie des données.
 
en gros ton modèle n'est plus un gros machin qui contient des données interrogeables, mais un machin qui génère des données ponctuellement, mais qui ne stocke rien.
 
La vue, elle-même ne peut pas se permettre de garder la représentation de ces données en mémoire va les transformer immédiatement à la réception de l'évènement et balancer dans la socket (on parle de web là).

J'ai un problème dans la relation controller - view. Je m'explique :
 
---------------------------------------------------------------------------------------------------------
Il est clairement dit dans pas mal de sujets sur le MVC que le Controller n'est pas un médiateur entre le Model et la View. Le Controller n'est pas là pour transmettre les données issues du Model à la View.
Le controller demande une action au Model, et informe la View que le Model a changé. C'est la View qui récupère les données.
---------------------------------------------------------------------------------------------------------
 
OK.OK !! Tout ça c'est très bien. Mais comment faire dans le cas suivant :
- Le Controller récupère une entrée utilisateur demandant une modification du Model.  
- Le Model effectue cette action, et dans la foulée, il renvoie 1 si l'action a réussi, il renvoie 0 sinon. C'est forcément la fonction qui effectue l'action qui renvoie 1 ou 0.
 
 
C'est là où ça coince. Pour afficher que l'action a réussi, comment faites-vous ?  
 
1) Le controller récupère la valeur 1 ou 0 et la transmet à la View pour affichage (cas du controller médiateur).
2) c'est directement la View qui récupère la valeur 0 ou 1 pour affichage. Ce qui veut dire que c'est aussi la view qui a lancé l'action sur le Model, et ça c'est n'importe quoi.
3) autre chose ?
 
En conclusion, j'ai beaucoup de mal à ne pas transformer mon Controller en médiateur entre Model et View, dans le cas où on veut afficher le résultat d'une action.  
 
Comment faites-vous ?

up de ma question, et je reprends le post de FlorentG pour la préciser :
 

 
Bon là on voit que le controller a instancié l'objet UserModel. Il transmet ensuite cet objet à la View qui va bien (UserListView), et la View va récupérer les résultats de UserModel grâce à un getter, et les afficher.  
 
Franchement, y aurait vraiment aucune différence si le controller récupérait le résultat directement et le transmettait à la view. Le controller transmettrait donc directement le résultat, et non un objet permettant d'obtenir le résultat. Moi personnellement, j'y vois aucune différence. D'où mes questions :
 
1) quelle est la différence entre transmettre à la view directement le résultat ou transmettre à la view un objet pour obtenir le résultat ... ?
2) N'avez-vous pas vaguement l'impression que ça donne au Controller un rôle de médiateur, ce qui n'est pas censé être son role ?
 
Personnellement, je vois pas vraiment le problème à avoir un Controller médiateur : je trouve qu'on rajoute des couches inutilement juste pour qu'il ne soit pas médiateur. Dans le Model, on va rajouter des getters à tout va pour que la View puisse récupérer les résultats, et lui transmettre des objets à tout va, au lieu de juste lui transmettre des résultats.
 
3) Où est le problème à avoir un Controller médiateur ?

 
Je vote pour le petit 1 ou 3 si on précise.
 
Le controlleur récupere le 1, qui indique que le modele a changé. Apres, il informe la vue que le modele a changé. Et pour finir, la vue récupere les données du modele (sans passer par le controleur) pour les afficher.

oui mais alors quel est l'intérêt de ne pas transmettre ce "1" directement à la view par le controler ?
Puisque pour que la View récup le résultat, soit elle va instancier un objet pour l'avoir, soit on va lui passer l'objet issu du Model en paramètre (voir mon post au-dessus).
 
Je vois pas l'intérêt de ne pas faire du Controller un médiateur. Quelqu'un peut me l'expliquer ?

A vue de nez, ça sera pas pour une question de couplage ?

bah ils m'ont déjà l'air couplés quand même, sans Controller, pas de View qui s'affiche
 
FlorentG et nraynaud ont disparu ?

non, mais j'ai d'autres trucs en tête.

chais pas, le controlleur il envoit des ordres au modèle, la vue est un observateur parmi tant d'autre du modèle et voiloù.
 
Le contrôleur est en générali lié à la vue, mais uniquement parce qu'il est représenté graphiquement à l'utilisateur, mais on s'abstient de les faire communique directement, parce que les autres observateurs du modèle sont intéressés par ce qu'il se trame.

ouki, la théorie je suis d'accord avec.
Mais tu es bien d'accord que ton Controller va devoir trandmettre un objet en appelant la bonne View (puisque on est dans un MVC passif).  
Pourquoi transmettre un objet plus qu'une variable ? (je sais je suis lourd )

Le problème vient du fait que le Controller ne sait pas quelles données la View a besoin.
 
Genre pour notre exemple, avec UserListView, on ne sait pas si la liste va afficher le nom de l'utilisateur, le prénom, l'âge, le nom du chien, etc... C'est la View qui sait elle-même ce qu'elle doit afficher. On lui file le Model, elle demande ensuite au Model les données dont elle a besoin, et ensuite elle les affiches.
 
Imagine avec un rôle de médiateur :
 

Et la View :

Là tout de suite un problème. Notre UserListView n'affiche que la liste des nom et des prénoms... Or, le controller lui a filé la liste entière, avec tous les champs (âge, nom du chien, de la petite soeur, etc)... C'est pas très optimisé tout ça.
 
Si la View peut choisir ses données, on obtient ça :

Et la view :

Déjà mieux, la View sait quelles sont les données dont elle a besoin, pas besoin d'aller chercher des choses inutiles.

oki effectivement, je comprends mieux.
 
Mais tu tombes bien, je suis en plein dedans là :
En général quand on a un formulaire pour récupérer des données :  
1) l'utilisateur soumet le formulaire qui part sur une page de traitement
2) la page de traitement fait ... le traitement, et redirige sur la page d'affichage
3) la page d'affichage ... affiche les résultats.
 
Et là je dois dire que j'ai du mal à conserver l'architecture MVC sans faire du controller un médiateur : en effet, la page de traitement va mettre en variable de session les résultats, pour que la page d'affichage les récupère. C'est donc forcément le controller qui balance la variable de session à ma view (la view pourrait récupérer elle-même la variable de session mais ça devient n'importe quoi).
 
Tu fais comment toi ? traitement et affichage sur la même page ?

Ouais, je suis actuellement en train de réfléchir au même problème

huhu oki, bah tiens nous au courant si tu avances, j'en ferai de même
(t'avais disparu où sinon ? )

J'ai des périodes comme ça où je viens plus... Enfin j'allais plutôt sur 4chan (oui, honte à moi). Et au bout de 2 mois, je reviens

k bah ouelcome baque ! ^^

oui moi aussi, apres un formulaire j'apelle un fichier qui fait les traitements, enregistrent les infos dans la session, puis  
je retourne sur une page specifique suivant ce que l'on a fait.
 
Puis dans cette page d'affichage y a juste des tests de vérification des variables de session.
Je pense pas qu'on ne puisse pas faire mieux en terme de séparation.
 
Il faut bien a un moment donné, mettre dans sa vue des infos dynamiques ...

perso comme j'aime pas trop que ça soit ma view qui bidouille des variables de session, c'est le controller qui lui transmet (cas du controller médiateur dont on parlait au dessus, et qui est sensé ne pas avoir sa place dans un MVC.
Bien que ça ne soit pas vraiment une médiation directe entre le model et la view : le controller récupère les résultats du Model et les met en session ; puis à la page suivante le controller récupère ces variables et les transmet à la view)
 
Enfin finalement, cette séparation controller - view me paraît moins primordiale que la séparation de la logique métier. Et certains modèles mélangent la view et le controller d'ailleurs. Alors, séparer au max, oui bien sur, mais c'est moins grave si ces deux couches sont un peu emmêlées

Vous pensez quoi de ce tutorial :
ftp://ftp-developpez.com/tahe/fic [...] 250305.pdf
 
Et vous avez testé phpmvc (www.phpmvc.net) dont ils parlent a la fin ?

voila un topic kilébon ... drapal

le lien est down pour moi

pas moi

ça remarche

 
Etant pourtant un intégriste du MVC, je suis d'accord avec ce compromis, tout au moins en PHP
Une fois qu'on a un schema de DB blindé et un solide modèle objet, le reste coule de source et peut être codé à l'arrache et/ou dans la précipitation mais ça dépend aussi comment on conçoit ses appli. De plus, l'humeur du client lambda étant tellement changeante en matière de design et de navigation (à 3 jours de la livraison), on est souvent amené à faire des bricolages.
 

 
Je commence à regarder et ça a l'air super interessant (dommage que ça soit pas en php 5, par contre). Comme j'en ai un peu marre d'avoir à réinventer la roue à chaque fois, j'avais dans l'idée (mais pas le temps) de me faire un tel framework MVC.

Pour ceux qui suivent pas, y'a aussi le Zend Framework qui pointe le bout de son nez. Ca à l'air prometteur, même si pour l'instant c'est surtout une libraire de fonctions utiles...

vi ça semble fort prometteur, mais assez inutile actuellement non ?