outils de modélisation pour symfony
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-plugin1 fonctionne plutôt bien
- Si vous utilisez Propel mysql-workbench-propel-export-plugin2 de générer le contenu de schema.xml, alors que SymfonyYamlMysqlWorkbenchPlugin3 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




[...] more here: outils de modélisation pour symfony » Vincent Mazenod, aka … If you enjoyed this article please consider sharing [...]
Ping by outils de modélisation pour symfony » Vincent Mazenod, aka … | Source code bank — 10 avril 2010 @ 12 h 43 min
Et l’inverse est-il possible ?
C’est à dire depuis un site symfony déjà existant, obtenir la représentation graphique de la base ?
Merci !
Commentaire by Philippe — 31 mai 2010 @ 22 h 40 min
A priori MySQLWorkbench est capable de modéliser un schéma de base de données existant. Par expérience, en revanche, il faut souvent crééer les relations entre les tables à la main :-/
Commentaire by mazenovi — 4 juin 2010 @ 11 h 48 min
Ok merci !
Commentaire by Philippe — 4 juin 2010 @ 13 h 24 min
On peut automatiser avec dbdesigner en gererant les tables et ensuite à partir de symfony, généré le modèle depuis la table existante
Commentaire by Henry — 11 juillet 2011 @ 11 h 24 min
@Henry absolument. Mais j’ai toujours à retoucher le YAML généré pour qu’il soit lisible :/
Commentaire by mazenovi — 12 juillet 2011 @ 16 h 12 min
[...] des applications PHP que je développe. Que ce soit avec DBDesigner pour symfony 1.0, ou avec MySQLWorkbench pour symfony > 1.2 [...]
Ping by PropelUtility le plugin propel en mode graphique pour MySQLWorkbench | Vincent Mazenod, aka mazenovi, aka voisin de gennetines — 20 octobre 2011 @ 13 h 37 min