Présentation de Symfony…

Introduction

Symfony est un framework PHP développé par une équipe française dont le chef d’orchestre est Fabien Potencier. Son but est l’accélération du développement et de la maintenance d’applications web, en se basant sur le modèle maintenant classique : Model-View-Controller. Il est gratuit et open source... Oui bon un de plus quoi… pas de quoi fouetter un chat ! Et pourtant ...

L’idée de base de Symfony semblerait être « ne pas réinventer la roue ». En effet le framework consiste à assembler divers projets reconnus existants, avec leur spécialités propres, en les liant dans une même structure de développement « tout en un ». De fait nous avons :

Une fois les « instruments » correctement orchestrés, il n’y a plus qu’à écouter la musique… (oui je sais, ça ne vole pas haut).

Pourquoi l’utiliser ?

Nous devions choisir un framework pour industrialiser les développements et simplifier la maintenance de tous nos projets. Après étude, le choix s’est porté vers Symfony, je vais tenter d’expliquer pourquoi.

Déjà, et ce n’est pas négligeable, la société l’éditant est française. Cela permet d’avoir un contact simple et rapide. Pour certains, il s’agit là d’un inconvénient ne jurant que par les américains ; pas pour nous : cocorico.

Ensuite, il répondait « sur le papier » à toutes nos attentes :

  • Compatible avec tous nos environnements
  • Simple à installer et à configurer
  • Apprentissage rapide
  • Fait pour gérer les nécessités de l'entreprise (différents univers, multi-connections...)
  • Evolutif sans toucher à sa structure de base
  • Tous les classiques du Web moderne inclus et simplifiés (ajax, multilingue, gestion du cache...)
  • Open-Source...

Nous nous sommes jetés à l’eau. Tentons de vous faire partager notre expérience…

Echafaudages applicatifs

Symfony découpe un projet en applications/modules/actions ce qui permet de rapidement mettre en place plusieurs couches à un projet unique.

Les applications

Il s’agit là de mettre en place des structures différentes d’accès aux mêmes données avec leurs problématiques ou leurs IHM propres. Elles sont totalement indépendantes les unes des autres et ne mutualisent que tous les objets d’accès aux données. Elles peuvent être exécutées sur plusieurs univers tapant sur des bases différentes avec les outil de débuggages actifs ou non…

Exemples d’applications d’un même projet :

  • Backoffice
  • Frontoffice
  • Interfaces…

Les modules

Les modules représentent les différentes section d’une application. Ils sont souvent lié à un objet ou à une partie importante de l’application.

Exemples de modules d’une application :

  • Utilisateurs
  • Forum
  • Statistiques

Les actions

Les actions permettent de structurer les différentes manières d’interagir avec un module. Elles se composent d’une partie view (templates) d’une partie contrôleur (dans la classe action du module).

Exemple d’actions :

  • Liste
  • Detail
  • Editer

La couche ORM (Object-Relational Mapping)

Les bases de données sont relationnelles et PHP5 et Symfony sont orientés objets. Pour faire communiquer les deux logiques, il est nécessaire d’employer une interface pouvant faire la passerelle entre les deux. Cette interface est appelée mappage objet-relationel (Object-Relational Mapping ou ORM)

Un ORM est composé d’objets donnant accès aux données tout en conservant la logique de métier.

Un des avantages de cette couche d’abstraction est qu’elle évite l’emploi de syntaxe spécifique à une base de données. En effet, cette couche traduit automatiquement les appelles au modèle objet en requêtes SQL optimisées pour la base employée.

Symfony génère automatiquement (via Propel) cet ORM en quatre classes pour permettre une liberté totale tout en conservant tous les mécanismes d’automatisations proposés.

Exemple : Objet est une table, quatre classes vont être générées :

  • ObjectBasePeer qui contrôle l’accès aux données
  • public static function doSelect(Criteria $criteria, $con = null)
    {
    	// generation automatique
    }
  • ObjectPeer qui permet de surcharger comme bon nous semble cet accès tout en gardant les automatismes de générations
  • public static function doSelect(Criteria $criteria, $con = null)
    	{
    // ajout d’une écriture de log avant de faire la selection effective
    		return parent::doSelect($con);
    	}
  • ObjectBase qui contient toutes les fonctions de base permettant de contrôler les objets « Object »
  • public function setVille($v)
    	{
    // generation automatique
    	}
  • Object à l’instar d’ObjectPeer cette classe permet de surcharger les fonctions de ObjectBase tout en permettant la génération automatique de ce dernier par la suite sans perdre nos modifications.
  • public function setVille($v)
    	{
    // mise en majuscule de la ville ou vérification de son existence…
    return parent:: setVille ($v);
    	}

Dans la pratique...

Dans la pratique il s’avère que le développement et réellement rapide. On peut générer tout un back office en ne concevant que le MCD (et quelques paramétrages rapide ;)) !

Expliquons l’utilisation « naturelle » de ce framework par l’exemple (il s’agit ici d’un survol général de la mise en place et non d’un pas à pas !)...

Vous souhaitez concevoir le classique projet « bibliothèque » mais avec une entrée interne pour gérer toute l’application, une interne pour gérer les location, une externe pour mettre en ligne le catalogue de votre établissement.

  1. Vous concevez le MCD et créez la base de données qui va bien
  2. Vous configurez symfony
  3. Vous laissez symfony générer le modèle XML de cette base par une ligne de commande :
    symfony propel-build-schema
  4. Vous laissez symfony générer les classes d’accès en construisant automatiquent les objets « livre » « rayon » « utilisateur »... correspondant à votre base
    symfony propel-build-model
  5. Vous créez une nouvelle application « backoffice » avec un module pour chaque objet
    symfony propel-init-admin mon_backoffice
    le backoffice est quasiment opérationnel
  6. Vous créez une nouvelle application « location » avec un module « livres » et un module
    1. symfony app location
    2. symfony module location livre
    3. symfony module location utilisateur
    4. Vous créez deux templates dans le module livre « listeSuccess » et « detailSuccess » et codez dans la classe action les fonctions indexListe() et indexDetail()
    5. Vous créez deux templates dans le module utilisateur « listeSuccess », « detailSuccess » et « locationSuccess » et codez dans la classe action les fonctions indexListe(), indexDetail() et indexLocation()

    l’application de location est quasiment opérationnelle
  7. De la même manière que 6 vous créez une application catalogue avec des modules et actions différentes.

Conclusion

Nous avons utilisé Symfony pour plusieurs projets. Il s’avère être très puissants pour mettre en place une application lourde donc l’évolution sera courante. En effet une fois la structure est en place, la conception et la maintenance est vraiment une partie de rigolade.

A noter également que la documentation de l’outil est impressionnante et exhaustive. Ses exemples couvrent un peu tous les axes de développements, et son pertinents et simple à appliquer.

Enfin, je ne le couvre pas ici, mais tout un package d’outils est inclus dedans (comme une puissante manière de gérer l’Ajax, prototype

En bref, un bon choix pour des projets importants, mais peut-être un peu lourd pour de petites applications.