15-12-2016, 10:58 PM
(15-12-2016, 10:32 PM)Xenos a écrit : Ou alors, t'utilise proprement le SQL, tu fais ta procédure stockée qui renvoie les infos sur un joueur, et tu ne fais qu'une mise à jour de la procédure au lieu de chaque requête. Le procédural n'a rien de dégueulasse. On peut faire du procédural sale en répétant tout partout. On peut faire de l'OO sale en déguisant le procédural en OO. On peut faire du procédural propre en centralisant les actions dans des fonctions réutilisées. On peut faire de l'OO propre en séparant bien l'instanciation des choses de leur utilisation (= en abstrayant ce que l'objet fait, pour lui déléguer les opérations à faire).
Mais comme la question porte sur "pourquoi pas C#?", je ne poursuis pas ce débat ici. L'atout de PHP ne réside donc que dans le fait de pouvoir faire des éditions rapides et à la volée, d'avoir un truc qui tourne rapidement et facilement (et oui, c'est essentiel, car c'est cette première pierre qui lance souvent les projets, qui seront par la suite rectifiés: "Make it Work, make it Right, make it Fast"). L'inconvénient évident, du coup, c'est qu'on a nettement moins d'aide de la part des analyseurs statiques et généralement moins de performances (l'interpréteur va toujours plus vite que l'interprété).
Mouais m'enfin partir sur une méthode de conception vielle de 12 ans (https://secure.php.net/releases/), en partant du principe qu'on referas "quand ça marchera", c'est du suicide. Aujourd'hui on parle de composants, de contrôleurs, de vues, de modèles, ... D'ailleurs tu le dit toi même, faire de l'OO dégueulasse, c'est la faire en procédural.
Donc je maintient mon avis. Si l'OP veut se lancer dans le C#, maîtriser le PHP en OO/MCV serait un plus.