Agence web et solutions IT, Experts Symfony contact@avanim-prod.com

Approche de Doctrine

11 octobre 2010 jravouna Symfony Étiquettes : , , , , , 0 Comments

Introduction

En utilisant les fonctions natives de PHP et le langage SQL, le développeur prend le risque de faire un code difficile à porter, peu flexible et en proie aux failles de sécurité. Nous allons voir dans cet article comment, grâce à la librairie d’Object/ Relational Mapping Doctrine, passer outre les requêtes classiques pour travailler uniquement à partir d’objets, avec tous les avantages que cela comporte.
Tout d’abord, qu’est-ce que l’Objet/ Relational Mapping (ORM) ? Il s’agit d’une solution pour le problème suivant :

Comment sauvegarder des objets dans un système de base de données relationnelle ?

Les deux concepts sont effectivement très éloignés. Pour y répondre, le système d’ORM va utiliser une carte des tables de la base et de leurs relations pour créer un comportement objet (Map Objects Relational = ORM) . Avec l’évolution actuelle de PHP qui est de plus en plus orientée objet, connaître un système d’ORM est un avantage certain. :lol:
Doctrine est une librairie d’ORM pour PHP débutée en 2005 qui prend actuellement de l’importance. La dernière version, la 1.0.6, requiert au minimum la version 5.2 de PHP,
ce qui montre la volonté des développeurs de créer et maintenir un outil d’actualité, utilisant les dernières fonctionnalités de PHP. Pourquoi choisir Doctrine et pas une autre solution d’ ORM Open Source ? Avant tout pour sa simplicité. :mrgreen:
Pas besoin d’écrire de longs fichiers de configuration ou de compiler quoi que ce soit à la moindre modification :quelques minutes suffisent pour mettre en place Doctrine
et commencer à coder. Ensuite pour le Doctrine Query Language, qui permet de créer des requêtes complexes tout en restant dans le milieu objet. Les nombreux outils bonus fournis avec la librairie sont aussi un avantage certain. Enfin, la documentation est très complète et mise à jour (voir encadré Sur Internet). 8-)

et Doctrine dans symfony, sa ressemble à quoi??

Sa ressemble a cela dans le répertoire lib/model/ :


Arborescence de Doctrine

Les tables et le mapping Doctrine utilisant entre autres le motif Row Data Gateway, chaque table aura une classe associée. Cela permet de séparer nettement les requêtes SQL de la logique métier de l’application. Doctrine générera une partie de ces classes pour vous, tandis que les relations entre les tables, les templates et autres événements devront être écrits à la main.
Plus précisément, Doctrine va générer 3 classes par table. Une première, nommée BaseNomdelatable contiendra les informations indispensables au fonctionnement de
l’ORM : le nom de la table ainsi que les noms et types des champs de cette table. La seconde, nommée Nomdelatable et vide lors de la génération des classes par Doctrine, servira à étendre la classe de base.

Les classes stockées dans le dossier Base correspondent aux classes de base et seront ré-écrites à chaque fois que la commande php symfony propel:build-schema sera exécutée, tandis que les autres classes ne seront jamais ré-écrites pour nous permettre de les éditer en toute sérénité. Vous remarquerez que les noms de table ont été transcrits au format CamelCase lors de la création des modèles : chaque mot commence par une majuscule et les underscores sont considérés comme des séparations de mots.
Il faut savoir qu’il est aussi possible d’utiliser des fichiers de configuration YAML (YAML Ain’t Markup Language) pour générer les modèles et les tables. Ce format, bien connu des utilisateurs de symfony, présente des avantages mais crée un intermédiaire supplémentaire qui complexifie légèrement l’application .

Les requêtes pour commencer en douceur…

Avant toute chose, sachez qu’il y a plusieurs méthodes pour gérer la base de donnée. La plus simple et rapide restant de laisser Doctrine les créer à partir d’une base de données déjà existante.

En pratique, vous pouvez soit:

  • Créer le schéma YAML de votre BDD  décrivant vos tables et leurs relations ( tel que ci-dessous)

  • Ou bien écrire à la main la classe de base du modèle comme ci-dessous:

Mais ne nous attardons pas trop dans la structure BDD, je pense qu’elle est assez explicite :mrgreen:

Faisons juste un petit tour vers le schéma YAML de votre BDD pous en voir le principal . Dans le fond, votre BDD tient dans un fichier : schema.yml stocker dans apps/frontend/config/schema.yml :

Prenons une table « Image » (quelquonque):

Puis sa définition YAML dans notre schema.yml…

Bon ok ma table est pas génial. :lol: Voici comment se lit un schema.yml:

  • La structure de la Table est déclaré par le mot « Column »
  • Les champs sont ensuite déclaré dans Column
  • Pour les 2 autres champs spéciaux actAS et relations,nous verrons cela plus tard…

Quelques règles concernant les champs de la table:

  1. primary:true -> Clef Primaire
  2. type: string(10) Son type (en l’occurance ici une  chaîne)
  3. autoincrement: true Si le champ est autoincrementé
  4. name: bookTitle as title son nom si vous voulez y mettre un alias de table
  5. default: test : sa valeur par défaut
  6. required:true si c’est obligatoire de remplire
  7. notnull : true : Valeur non null
  8. length : 12 Longueur du champ (espace alloué)
  9. unsigned: true Non négatif

Voici en gros  les principaux type de données en YAML traduit en SQL:

  1. type: integer(4) les INTEGER
  2. type: boolean BOOLEAN
  3. type: float(10) FLOAT
  4. type: decimal(18) avec scale: 2 pour lui préciser le nombre après la virgule DECIMAL
  5. string(60) correspond à VARCHAR(60) avec fixed:60 pour fixer une longueur précise
  6. type: array(10000) pour les Array
  7. type:object pour les type Objet
  8. type: blob pour les Blob (Binary Large OBject)
  9. type:timestamp pour les TIMESTAMP
  10. type:time pour les time
  11. type:date pour les types DATE
  12. type:gzip type STRING compressé (exemple JPG)
  13. type:enum pour les valeur enuméré avec le type values:

Source : http://www.symfolive.com/petite-approche-de-doctrine-partie-1/

Submit a comment