Symfony à radicalement changer mon approche du développement PHP.

En effet l’approche RAD proposée par ce framework rend d’autant plus crucial le schéma de base de données, sur lequel est basé l’application. Ce schéma matérialisé par le fichier schema.yml (ou .xml si vous utilisez propel) est en quelque sorte la feuille de route du développeur agile.

Il est intéressant de remarquer qu’une modélisation graphique de ce schéma donne un point de vue (partiel certes) sur le système d’information que l’applicaiton sert …

Il ya déjà quelques temps déjà j’avais cherché à automatiser la modification du schéma géré par symfony via des outils graphiques (Utiliser DBDesigner avec l’i18n de symfony 1.0)

Aujourd’hui je vous propose un petit tour d’horizon des solutions à votre disposition selon vos outils et votre orm préférés

DbDesigner

si vous utilisez propel

• Le plugin sfDB4toPropelPlugin automatisera le processus de conversion du schéma sauvé par DbDesigner en un schema.yml (à la manière des scritps cités précédemment)

si vous utilisez Doctrine

le plugin sfDbDesignerPlugin ne s’installe pas correctement via la commande symfony. En revanche en l’installant manuellement, i.e. en téléchargeant l’archive directement sur le site et en la décompressant dans /plugins/sfDbDesignerPlugin puis en activant le plugin dans /config/ProjectConfiguration.class.php

<?php

require_once dirname(__FILE__).'/..\lib\vendor\symfony\lib/autoload/sfCoreAutoload.class.php';
sfCoreAutoload::register();

class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
    $this->enablePlugins('sfDoctrinePlugin');
    $this->enablePlugins('sfDbDesignerPlugin');
  }
}

vous aurez accès à la task

php symfony dbdesigner:convert-doctrine doc/database.xml

Où doc/database.xml est le path vers le fichier DBDesigner.
Si vous n’avez pas une application nommée frontend il faudra la passer ne paramètre

php symfony dbdesigner:convert-doctrine --application=myapp doc/database.xml

vous obtiendrez alors un fichier « ready to build » du schéma modélisé avec DBDesigner dans config/doctrine/schema.yml

MySQLWorkBench

Il est à noter que MySQLWorkbench est un fork de DBDesigner4, mais il ne peut pas remplacer ce dernier. En effet si MySQLWorkbench sait parfaitement importer un fichier xml produit par DbDesigner4, il est en revanche incapable d’exporter ce schéma au format xml de DbDesigner4.  MySQLWorkbench ne permet que d’enregistrer au format mwb.

Ce format est en fait un zip, qui une fois décompresser donne un fichier xml, mais qui n’a rien à voir avec le xml généré par DBDesigner4, le fichier xml issu du .wmb est donc inutilisatble avec les deux plugins ci dessus.

MySQLWorkbench bénéficie en revanche d’une bibliothèque de plugins qui permettent de l’utiliser en remplaçant de DBDesigner.

Pour installer un plugin dans MySQLWorkbench il suffit de copier le fichier .lua qui contient le code du plugin (du Python Like) dans le répertoire « modules » du répertoire d’installation de MySQLWorkbench

• Si vous utilisez Doctrine mysql-workbench-doctrine-plugin¹ fonctionne plutôt bien
• Si vous utilisez Propel mysql-workbench-propel-export-plugin² de générer le contenu de schema.xml, alors que SymfonyYamlMysqlWorkbenchPlugin³ vous permettra de générer le contenu de schema.yml

Dia

Si vous utilisez propel, il est possible de modéliser également votre schéma avec Dia grâce au plugin diaToPropelPlugin, en utilisant la boite à outil « Database » ça va sans dire.

Si vous utilisez Doctrine le plugin ConvertPropelSchemaToDoctrineSchema réalisera la conversion d’un schéma propel en schéma doctrine.

ArgoUML

En graltant un pei plus j’ai trouvé également le plugin uml2symfony, qui semble avoir l’ambition de traduire non pas un schéma de base de données, mais un schéma UML généré avec ArgoUML. Je vous laisse aller plus loin car j’ai personnellement trouvé l’idée séduisante mais la documentation très pauvre, voir inexistante!

Conclusion

Mon choix se portera sur le doublette gagnante MySQLWorkbench, mysql-workbench-doctrine-plugin car:

• DBDesigner n’est plus maintenu depuis belle lurette (je me rends compte en écrivant ce post que DBDesigner fork qui a dormi pendant prêt de 3 ans semble revenir à la vie depuis quelques jours)
• j’utilise maintenant Doctrine
• ce plugin permet une gestion fine des Behaviors Doctrine