Reprise du message précédent :

 
ben si, mais où est-ce que j'ai parlé de la partie qui gère l'affichage, moi?
J'ai dit que j'accédais directement à la base sans surcouche dans le modèle, c'est tout...

 
Je suis pas sûr de bien faire le lien entre ce que tu racontes et ce que j'implémente exactement derrière.
 
Ca donnerait une classe TransactionManager (un singleton, je suppose?), qui stocke la connexion et effectue toutes les opérations sur la base lui-même?
Et à ce moment là dans toutes la classes de mon modèle j'instancie cette classe quand j'en ai besoin...?

J'ai trop l'habitude d'utiliser les terme "modéle" en rapport avec le "gestionnaire de modéle d'affichage" (j'aime pas le terme template. ) quand je parle de la partie qui s'occupe de l'affichage.
J'ai donc crus que tu parlais de ça quand t'as dit que t'avais des accés à la base de donnée directement dans ton "modéle".

nan, tu fais un  

Ce que je pense faire, c'est un truc du genre :
 
Toutes les actions & commandes viennent dans des objets Command (voir Command Pattern ) :
[considérez ces exemples comme du pseudo-code]

 
Pis on a un système de "Filters". Avant de lancer la command, on exécute différents filtres, qui s'occuperont de voir si la commande nécessite une connexion, une transaction, une authentification. Pis après la commande, on réexécute les filtres s'il le faut. Ca permet de gérer automatiquement tout ça.

 
ah, ok...

up de ce topic important, j'ai débuté mon propre framework en MVC, vu que pour apprendre faut se lancer
 
Je séparais deja les couches controles/vues des modèles, dans mes dev précedents. Séparer la couche de controles de la couche de vue, ca a pas l'air super difficile non plus
 
Je vous emmerderai si j'ai des problèmes

au fait, je vous rappelle que dans le monde normal, la vue est un listener du modèle.

Ouais, dans le monde normal Le modèle y est "actif"... Par contre en web, il est "passif"... C'est le contrôlleur qui dit à une vue de s'afficher... Pas le modèle

Pour le système de template en XSLT, j'y réfléchi aussi de plus en plus, en fait tu génères un fichier XML avec tes données puis tu le passe à XSLT avec une feuille de style qui va bien pour afficher ce que tu veux ? Perso je pensais faire ainsi mais si c'est pas ça t'aurais un exemple ?

Sauf erreur, c'est bien comme ca que fait florentG il me semble.
 
BDD/PHP > XML > XSLT > Whatever si je me trompe pas.

1) en .net (Webcontrols) ça marche aussi.
2) le contrôleur n'a rien à dire à la vue. le controleur agit sur le modèle, c'est ce dernier qui va prévenir la vue (et tous ceux qui l'observent en général) qu'il s'est modifié.

 
Ca me parait plus une question d'interprétation qu'autre chose, ça, non?
La vue ne sera pas modifiée si le modèle n'est pas modifié, mais dans la pratique on est obligé de demander à la vue de réafficher dès qu'on veut faire intervenir le controleur...
Par contre je suis tout à fait d'accord sur le fait que le controleur ne doit avoir aucune incidence sur ce qu'affiche la vue...

Voilà
 

Je voulais dire que le contrôleur instancie la bonne vue. Par contre en web, difficile pour le modèle de dire à la vue qu'il s'est modifié...

Donc logiquement, en web moi je verrais un controleur principal, qui, selon la requete du client, instancierait un controleur spécifique à l'action, qui lui même instancierait le modèle et la vue qui vont bien.
 
Parce que la notion d'observers, en web, je vois pas trop comment ce serait possible ...

Observer Pattern

Assez impressionnant. Fallait y penser

Je t'explique pas le temps d'exécution sous PHP4 sans opcode-cache

 
 
[un peu HS]
Dans le code d'exemple, on peut lire ceci :
 

 
A l'affectation le & est encore nécéssaire?
Puisque l'objet passé en paramètre est déjà une référence, je vois pas pourquoi...
[/un peu HS]

Sauf que si tu fais :

Tu mettera dans $this->observers[] une copie de $observer Faut des & partout

Bah je c'est une implémentation assez classique, non?

 
 
Oui, mais une copie de la référence pointera au bon endroit, non?

Et pour la gestion de la base de donnée vous utilisez singleton ?

 
Pas encore, mais si j'ai le temps de m'y atteler, oui.

ch'ais pas    Faudrait tester
 

DAO + Singleton...

 
Bah d'après mes tests ça a l'air de marcher...
 
[edit]
 
Mais je vais modifier quand même, dans le doute...ça évitera au moins de dupliquer la référence pour rien...

Au fait, c'est quoi "singleton"? une extension de php ou juste uen technique permettant d'avoir les même valeur dans tous les objets d'une classe donnée?

 
un design pattern...

singleton pattern (super utile ce site , dommage qu'il a été down pendant 2 semaines)

ok, me rapellais plus du mot clé "static".
Ca va m'éviter de trimbaler certains objets dans tous les sens. Heureusement que vous me rapellez ça maintenant vu que j'ai a peine commencé la future version de mon site.

> singleton pattern
je vais embrayer là-dessus si vous le voulez bien
 
je me demande bien, au delà du design, quel est l'impact sur les perfs de l'usage d'une classe (qui aurait besoin d'être une instance unique) soit en instance Singleton ou hors du context objet (avec stockage déporté) ...
 
pour être plus clair : est-il plus interressant "performance wise" d'instancier, par exemple, un transactionManager, auquel cas l'objet stocke ses membres, ou d'appeller direct des fonctions static, auquel cas les éventuels "membres" sont stockés en dehors du context objet (niveau global ou autre stockage) ?
 
ok c'est un peu théorique, car encore une fois c'est pas vraiment une question de design spécifique, mais plus une reflexion sur les perfs ... et finalement ça impact sur l'usabilité, car finalement je trouve plus pratique d'appeller une func. static plutôt que de trimbaler une instance (à l'intérieur des classes utilisant, par ex., notre transactionManager) ...
 
en même temps, j'ai qu'a tester me direz-vous ...

Moi j'appelle des fonctions statiques sur une classe qui trimballe une instance d'elle-même Donc un singleton utilisé pour un accès à une classe statique et global...

pas mal, j'en ai une comme ça aussi    
au début ça me semblait un peu capilotracté, mais ça a l'avantage des deux ...

Bien, après quelques jours de réflexions complètes, j'ai décidé d'abandonner quelque peu l'idée d'avoir une abstraction totale vis-à-vis de la source de données... Surtout après avoir lu un post là-dessus... Etre totalement abstrait est vraiment trop difficile, limite un peu la liberté, risque de porter atteinte aux perfs, et ne diminue le temps de développement que légèrement en cas de changement de SGBD...
 
Théoriquement, avoir une abstraction totale veut dire : on peut chercher les données à partir d'une base MySql, Oracle, SQLServer, un document XML, un fichier texte, via un socket qui utilise un protocole réseau obscure, etc.
 
Alors pour ce qui est des SGBD conventionnels (MySql, Oracle...), y'a déjà tout l'SQL qui change... Sélectionner les enregistrements 10 à 30 sous MySql ne se fait pas de la même manière sous Oracle, pas non plus sous Postgre... Pire encore, si on a un fichier XML ou CSV, y'aura même pas d'SQL du tout (XPath pour l'XML, et parsing pour le fichier texte)...
 
Après y'a aussi l'organisation des données qui changent. Imaginez une hiérarchie d'éléments. Sous un SGBD, vous pouvez utiliser une liste adjacente, donc une table qui contient des champs id, parent_idet title. Puis on reconstruit l'arbre via récursivité. Avec un fichier XML, même pas besoin de stocker l'id du parent, il suffit de stocker l'élément dans son parent. Donc niveau représentation des données, ça fait un champ qui saute...
 
Pour revenir au niveau des requêtes SQL, se pose le problème des clauses WHERE... Là aussi c'est le merdier. Pareil pour les types de champs... Certains ont des types de champs (genre Postgre qui a des types géométriques ), qui sont représentés totalements différemment chez d'autres (ici notre type Postgre 'point' devra par exemple être sous formes de deux int sous MySql). Rajoutez là-dessus la présence ou non de procédures stockées, et on s'en sort plus...
 
Bref, un merdier total, une infinité de possibilité... Faut carrément un layer supplémentaire, que je baptiserais "Data Access Logic", qui serait chargé par exemple de traduire les types de données entre PHP et la solution de stockage...
 
 
 
Donc, ce que j'ai fais, c'est définir des DAO génériques de bases, sous forme d'interface. Par exemple, j'ai un ITableDao, qui définit des méthodes pour gérer une table (enfin une liste d'éléments pour être plus précis, vu que la notion de table n'est pas présente partout), donc ajout, modification, suppression, listing, etc.
 
Après j'implémente ces DAO pour telle ou telle technologie, je me retrouve avec des MySqlTableDao, XmlTableDao, etc.
 
Pis après si y'a des impératifs spécifiques, genre sélection selon un critère ou calculs spéciaux, je définis une nouvelle interface, qui hérite de ITableDao, et qui définit les méthodes spécials. Puis pareil, je fais l'implémentation suivant les différentes technologies.
 
Exemple :
 

 
Donc en théorie, les DAO génériques devrait être tous fait (bon, ça, on verra dans le temps, pour l'instant je vais faire ceux pour MySql et fichiers XML). Après, si changement il y a, suffit de refaire les DAO spécifiques, et ça roule...
 
Qu'en pensez-vous ?

les singletons c'est le maâââal

Touriste J'ai pas de singleton là

 
ah ?

Ouais C'est pour la class Config... Comme ça n'importe qui a accès à la config et à ce qui l'intéresse... Mais c'est un truc auquel je dois encore réfléchir...

Je rappelle au passage que découpler les données de la base, ça permet aussi de tester avec des fakes, de développer indépendament de la base pour diviser le boulot, d'injecter des données bizzares dans les tests sans se faire chier, et d'avoir un design plus modulaire (parce qu'au moins y'a pas de SQL dans le business).

Voilà, je pense que tout le monde est d'accord de n'avoir aucun SQL dans la logique métier. Après c'est le layer en dessous qui pose problème : abstraction ultime ou non. Moi j'ai choisi quelque chose au milieu...

Moi j'ai du SQL dans le métier et je vous merde.
Mais d'un autre coté j'aimerais bien reprendre ce code...