./2228En partie parce que la DB appartient à un métier différent de celui du développeur (au mieux à un admin db, à défaut à l'admin système). La DB contrôlée par le dev fait parti de la configuration répandue "le dev fait tous les aspects du code" (db, front, back, parfois même la config serveur).
De fait, devoir synchroniser en permanence deux codes... oui. C'est aussi le cas si tu as un dev frontend, il va avoir besoin que le backend lui envoie de nouvelles données s'il vient à changer son affichage. C'est une affaire de communication dans l'équipe, pas d'hypercentralisation.
flanker (./2230) :
C'est nettement plus pénible quand tu as quelques dizaines de classes avec des contraintes d'intégrité de partout, ainsi que des index particuliers. Et quand tu rajoutes un clef étrangère à une classe parente de 5 ou 6 classes, il faut modifier, toujours à la main, les 5 ou 6 tables SQL (au bon endroit ! )…
On n'est peut-être pas d'accord sur la façon de développer un projet. Ce que j'ai toujours fait, en revenant le projet/CdC, c'est travailler la base de données, concevoir des tables, réfléchir aux besoins du client (avec les index pour la recherche, les contraintes de champs et de clés étrangères, d'unicité, etc), et tout cela doit être finalisé avant de commencer à écrire la plus petite ligne de code.
Je ne conçois pas la DB au fil du développement, c'est la base de mon projet. Autant dire que je ne retourne jamais sur la DB ensuite, à l'exception des nouvelles demandes clients (pour lesquelles, là encore, je fais les modifs DB avant toute autre chose).
Aussi, dans
mon cycle de développement, concevoir la DB via le code m'est non seulement inutile (je n'ai pas besoin de régénérer la DB par la suite), mais en plus contre-productif (je suis plus efficace en concevant ma DB par un outil d'administration DB comme Workbench, ou même à défaut par phpMyAdmin, qu'en y tapant du code. Sans compter l'importance des schémas de relation quand tu travailles avec des DB ayant des dizaines de tables, et ça arrive assez souvent pour une clientèle professionnelle).
flanker (./2230) :
mais au fait, de quel SQL parles-tu ? SQLite ? OracleSQL ? Postgresql ? MySQL ?
Je ne pense pas que ce soit un problème. Avec "SQL" je parle de mon côté de MySQL, mais par l'expérience (et des clients aux configs différentes) je connais les plus grandes différences avec Oracle, SQLite, et Transact SQL. C'est essentiellement un point de détail.
flanker (./2230) :
au final, par expérience et même avec des requêtes compliquées, je n'ai jamais besoin de pondre du SQL
Là on est dans la théorie, et elle fonctionne du côté code, je le conçois. En revanche, la pratique impose parfois d'aller au-delà du code. J'ai régulièrement besoin d'ouvrir Workbench pour aller corriger de mauvaises données, supprimer des enregistrements douteux, etc (c'est toujours une merveille quand on bosse avec un client qui a besoin d'un import Base pro -> SQL quotidien rempli de cas particuliers).
Pour tout ce que je défends de mon approche du problème, je visualise bien l'intérêt de ta génération du SQL et les avantages que cela apporte. Il est certain qu'une faiblesse (un exemple parmi d'autre) de mon approche est qu'il est difficile de synchroniser sa DB de dev avec des collègues si elle se situe en localhost.
./2233Tu es un peu à la bourre à sortir la doc de CakePHP 2.x, mais il faut reconnaître qu'il est très populaire. Même si CakePHP fut l'un des premiers gros frameworks PHP, il est resté en retrait en 2.x sur la concurrence (par ex de tout vouloir faire passer par des arrays que des méthodes).
La règle des pluriels avait pour but de permettre un fonctionnement simple du système de convention automatique (pour que le framework différencie Apple et Apples par exemple parmi la structure du code). C'est un point particulier, et moi-même ne suis pas certain que ce soit la bonne chose à faire, en parti à cause du pluriel irrégulier.
Je ne me pose pas la question en français, car une bonne pratique (à mon sens) est que le code soit en anglais.
Et justement dès lors, en dehors du pluriel, le reste de la convention fait parti des bonnes pratiques PHP sur les règles de nommage : fichier en PascalCase, pareil pour les classes, méthodes en camelCase... l'url de la méthode appelée doit être en snake_case simplement parce que les urls sont case-free.
J'insiste une fois encore pour dire que c'est de la convention automatique. Le fichier de routing par ex permet de redéfinir les appels url->méthode.
Mais je vais rester sur ton idée que c'est une question de goût, parce qu'en effet ça ne m'a jamais posé de problème, même au moment d'apprendre le framework. Seule la question du pluriel m'a effectivement fait tiquer. Mon plus récent collègue qui vient d'un entreprise Symfony a mis quelques jours à s'adapter à CakePHP mais n'a jamais remis en question ses conventions de nommage.
Je ne défends pas mon beefsteak en prétendant que ce framework est le meilleur
simplement que je n'arrive pas à saisir la critique faite. Peut-être en effet une simple question de goût.
./2243D'accord avec toi sur le coup. Pour autant que cette fois semble bizarre, ce n'est pas le code qui m'effraie mais de découvrir les différences majeures de règles de pluriel. Les liens fournis dans la doc intégrée de calculate() sont intéressants à lire.
)
simplement que je n'arrive pas à saisir la critique faite. Peut-être en effet une simple question de goût.