POO et DB

[christouphe]

si je suis bien ce qui est écrit, et que j'ai bien compris:

Récupérant 10 news, je créé un seul nouvel objet et je le clone 9 fois en modifiant ses attributs, à condition que tous ses attributs soit modifiables, ça va de soit.

[Kihmé]

si je suis bien ce qui est écrit, et que j'ai bien compris:

Récupérant 10 news, je créé un seul nouvel objet et je le clone 9 fois en modifiant ses attributs, à condition que tous ses attributs soit modifiables, ça va de soit.

Je n'utilise pas le clonage et pourtant une même variable me sert à instancier plusieurs objet différents


NicoMSEvent à propos de la volatilité j'ai lu quelque part que la sérialisation dans un fichier, par exemple le cas des sessions, on peut sérialiser un objet et le passer dans une variable session était à éviter. Ce serait de l'ordre d'un fichier par utilisateur rien que pour les sessions. Donc il faut vraiment éviter car le serveur risque de trinquer. Après ton idée de sérialiser dans un fichier commun je ne vois pas la différence pour le serveur, tu n'auras qu'un fichier mais il va être très gros. Le plus léger resterait de stocker un fichier chez l'utilisateur...

J'ai opté pour sérialiser et faire passer par la barre url, je fais ça pour un seul objet pour le moment, peut être il peut être intéressant de voir à passer plusieurs objets. Mais l'url ça m'embête un peu car c'est visible et donc me semble pas très sécurisé. Je suis vraiment curieux de savoir comment les outils ORM genre doctrine gère ça, quand j'aurais le temps j'irais voir ça, ou même demander à une équipe spécialiser dans les jeux par navigateur...

[Cartman34]

Linéariser un objet pour le faire passer par l'url n'est pas une meilleure idée, l'utilisateur peut donc mettre ce qu'il veut dedans et puis c'est bien lourd pour quelque chose que tu balades sur chaque page !!
Enfin, je pense que la solution de la session n'est pas si mal, je l'utilise et c'est très efficace.
Les sessions utilisent un fichier de toute manière, ce qu'il contient n'a pas grande importance du moment que c'est utilisé (je veux dire par là que si ta session est bourrée de variable que tu n'utilises pas, là c'est pas terrible), la capacité du disque dur n'est plus un soucis de nos jours !

[Sephi-Chan]

Pour stocker des objets partagés entre plusieurs utilisateurs, tu peux utiliser APC, Memcached, MongoDB ou tout autre système de stockage par couple clé/valeur. Ceux là te demanderont souvent un serveur dédié.

Tu peux aussi coder ça toi même, bien que tu as plus de risques de faire des conneries.

Tu peux également développer ça sous forme de Web service (si les données ne craignent pas), à qui tu donnes une clé et qui te rend un objet JSON (par exemple). Ainsi, ça te permet de gérer facilement le cache, de faire ça sur un serveur mutualisé, etc.


Sephi-Chan

[Kihmé]

ouai je viens de faire un test, il suffit de déformer l'objet qui est dans l'url pour faire planter l'application. Donc la session... Si quelqu'un utilise un autre moyen ça m'intéresse.

[Anthor]

Attention tout de même, un objet de DB sérialisé, ne sera plus connecté une fois dé-sérialisé. ^^

[NicoMSEvent]

d'où l'intérêt de ne mettre en cache (sérialiser) que ce qui serait permanent, ou ce qui n'est pas sujet a trop de modifications (par exemple les différents types de terrain ou d'unités avec leurs stats de base)

ça devrait également être possible de pouvoir modifier le cache en cas de modification des objets visés

[Anthor]

Tu as aussi le cache de MySQL qui permet déjà une bonne performance.

Ensuite, le cache s'implémente en 4 lignes, si tu as bien séparé tes objets.

Une ligne, dans la mise à jour pour vider le cache, et 3 lignes à l'instanciation pour mettre à jour.

Code PHP :

<?php 

class cachedClass {

    private $_object = null;



    public function __Construct()

    {

        $this->_getCache();

    }



    public function update()

    {

        // UPDATE



        $this->_getCache();

    }



    private function _getCache()

    {

        $this->_object = // Ce que l'on veut;

    }

} 

[Kihmé]

Attention tout de même, un objet de DB sérialisé, ne sera plus connecté une fois dé-sérialisé. ^^

j'ai opté pour l'utilisation d'un attribut id dans mes objets qui me sert qu'à vérifier les correspondances lorsque mes objets sont recréés à partir de la bdd.