MVC Design Pattern: les responsabilités

[Maz]

Merci à vous deux pour votre vision de ce type de structure.

Si ça peut t'aider à le concevoir, tu as le droit d'avoir des modèles qui ne correspondent pas à ta base de données. Généralement on appelle ça des service objects.

J'aime beaucoup le principe de "service objects", dans quel cas je pense créer comme je disais une classe controller + modèle propre à ce "Bâtiment" qui ne serais lié à aucune de mes tables directement et qui gérerais toutes les actions réalisables dans ce bâtiment: création d'unité, sacrifice, développement des unités etc...

Du coup ce schéma est aussi réutilisable pour tout mes "bâtiments" qui effectues des actions groupées sur différentes tables. J'aime cette idée.

Tu noteras que je fais appel à de nombreuses méthodes statiques. Je trouve que dans les jeux, passer des ID a souvent de bien meilleurs résultats que des objets complets (souvent issus de l'ORM) qui nécessitent plein d'appels inutiles à la base. Ça colle parfaitement avec ta volonté d'utiliser ta base de données directement plutôt qu'à travers l'ORM.

+1 pour les fonctions statiques, effectivement je pense que dans des développement de jeux dans lesquels il y a énormément de relations entre les tables, certaines requêtes deviennent très complexes et inutiles avec les orm dans des relations.

Pour MVC, je ne sais pas si tu classes ça dans "controlleur" ou dans "modèle" (je serait tenté de dire "controlleur" car cela contient de la logique) mais je rejoins l'approche de faire une autre "classe" (ou autre concept du langage) controlleur appelant les deux "classes" de modèles pour que ce controlleur dise aux deux modèles de faire la suppression d'unité et l'ajout de ressources

Corriges moi si je me trompes, mais je dénotes ici que tu serais plus pour mon approche initiale: un contrôleur différent (ni Unity, ni City) qui appelerais directement les deux modèles depuis le contrôleur pour leur demander d'exécuter le traitement des données.

Tu trouveras en PJ J'ai copié-collé en bas de cette message le début de la discussion avec Sephi, ça as été le point de désaccord.

Et du côté de mes archis, la page "/game/action/city/sacrifice" serait un endpoint qui appelle sa procédure stockée dédiée, dans laquelle on aurait bêtement:

CREATE PROCEDURE game_action_city_sacrifice(

IN idPlayer INT UNSIGNED,

IN idCity INT UNSIGNED,

IN idSacrifiedUnit SMALLINT UNSIGNED

) BEGIN



-- Code raccourci



END

$$

Tu noteras sur la dernière ligne de la discussion Discord, les procédures ont été évoqué, le "soucis"(avis personnel), avec ce type de "logique déportée en base de données" bien que probablement très performante niveau benchmark pour des requêtes lourdes, je trouve que l'on y perds en visibilité dans le code du moteur du jeu.

Bien que le développeur initial sais très bien ce que va faire exactement la procédure "city_sacrifice", il est délicat pour un nouveau programmeur rejoignant le projet de le deviner, il doit donc aller chercher dans les migrations ou directement sur la base de donnée sa description, ou pour contrer ce phénomène, ajouter un docblock qui selon la complexité de la procédure serais cossue.

De plus, dans certains cas (comme celui que je dois résoudre), il me faut connaître des paramètre que je stock dans un fichier php de type "game config" du genre le taux d'incrémentation de la nourriture par unité sacrifiée.

Tout est réalisable dans cette configuration, mais cela rajoute je trouves une fine couche de complexité, à chacun d'en juger le coût et le gain et d'utiliser ou non une solution similaire.

Maz:
  oui, on est d'accord, quand je dis "supprimer le modèle"
  c'est genre

Code PHP :

<?php 

eatEggs($nb_fourmis) {

Ant::delete($b_fourmis);

City::increaseFoodFor($nb_fourmis);

// Ici j'envoie la vue

}