Development

sfBookFRmodel (diff)

You must first sign up to be able to contribute.

Changes between Version 1 and Version 2 of sfBookFRmodel

Show
Ignore:
Author:
godai (IP: 64.236.227.6)
Timestamp:
07/26/06 16:56:41 (11 years ago)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • sfBookFRmodel

    v1 v2  
    11= Le Modèle dans symfony = 
    22 
     3 
    34== Présentation == 
    45 
    56Symfony utilise une couche d'abstraction objet/relationnel basée sur Propel pour se connecter aux bases de données. Propel permet d'accéder et de modifier facilement les données stockées dans une base en utilisant des objets à la place de requêtes SQL. Ce chapitre détaille l'utilisation du modèle de données objet dans Propel et illustre son utilisation au sein de symfony. 
    67 
     8 
    79== Pourquoi utiliser une couche d'abstraction ? == 
    810 
    1719Une couche d'abstraction gère l'extraction des données. Le reste de l'application ne nécessite pas de requêtes SQL et le SQL qui accède à la base est facile à trouver. Les développeurs spécialisés dans la programmation de base de données s'y retrouvent également. 
    1820 
    19 Le fait d'utiliser les objets à la place d'enregistrements et les classes à la place de tables a un autre avantage : ils permettent d'ajouter des accesseurs à vos tables. Si par exemple vous avez une table 'Client' avec deux champs 'Prénom' et 'Nom', vous pourriez être intéressé pour récupérer uniquement le nom complet. Dans un environnement orienté objet, il suffit d'ajouter un nouvelle méthode accesseur à la classe `Client`. 
     21Le fait d'utiliser des objets à la place d'enregistrements et des classes à la place de tables a un autre avantage : cela permet d'ajouter des accesseurs à vos tables. Si par exemple vous avez une table 'Client' avec deux champs 'Prénom' et 'Nom', vous pourriez être intéressé pour récupérer uniquement le nom complet. Dans un environnement orienté objet, il suffit d'ajouter un nouvelle méthode accesseur à la classe `Client`. 
    2022 
    2123{{{ 
    2628}}} 
    2729 
    28 Les fonctions qui font des appels répétitifs aux données et la logique métier des données elles-mêmes peuvent être conservés dans de tels objets. Prenons l'exemple d'une classe 'ShoppingCart' dans laquelle vous conservez les produits sous forme d'objets. Pour connaître le montant total du panier lorsque la commande est terminée, vous pouvez utiliser la méthode suivante : 
     30Les fonctions qui font des appels répétitifs aux données et la logique métier des données elles-mêmes peuvent être conservées dans de tels objets. Prenons l'exemple d'une classe 'ShoppingCart' dans laquelle vous conservez les produits sous forme d'objets. Pour connaître le montant total du panier lorsque la commande est terminée, vous pouvez utiliser la méthode suivante : 
    2931 
    3032{{{ 
    4446[http://propel.phpdb.org/trac/ Propel] est actuellement l'une des meilleures couches d'abstraction pour PHP5. Plutôt que de la réécrire, symfony l'intègre de façon homogène au sein du framework. 
    4547 
     48 
    4649== Le modèle de données == 
    4750 
    5457=== Exemple === 
    5558 
    56 Imaginons que vous ayez une base de données 'blog' avec deux tables 'blog''article' et 'blog''comment' qui contiennent des données. La structure est la suivante : 
    57  
    58 || blog_article || blog_comment || 
     59Imaginons que vous ayez une base de données 'blog' avec deux tables 'blog_article' et 'blog_comment' qui contiennent des données. La structure est la suivante : 
     60 
     61|| '''blog_article''' || '''blog_comment''' || 
    5962|| id || id || 
    6063|| title || article_id || 
    6669 
    6770{{{ 
    68 propel: 
     71 propel: 
    6972   blog_article: 
    7073     _attributes: { phpName: Article } 
    8285}}} 
    8386 
    84 Vous pouvez remarquer que le nom de la base de données (`blog`) n'apparaît pas directement dans le fichier `schema.yml`. A la place, la base est référencée sous un nom de connexion (`propel` dans notre exemple). Ceci parce que les paramètres de connexion actuels peuvent dépendre de l'environnement dans lequel votre application fonctionne. Par exemple, lorsque vous êtes en phase de développement, vous accédez à la base de développement, mais avec le même schéma que la base de données de production qui, elle, n'utilise pas les mêmes paramètres de connexion. Ces informations seront spécifiées dans le fichier `databases.yml` (voir ci-dessous). 
     87Vous pouvez remarquer que le nom de la base de données (`blog`) n'apparaît pas directement dans le fichier `schema.yml`. A la place, la base est référencée sous un nom de connexion (`propel` dans notre exemple). Ceci parce que les paramètres de connexion actuels peuvent dépendre de l'environnement dans lequel votre application fonctionne. Par exemple, lorsque vous êtes en phase de développement, vous accédez à la base de développement, mais avec le même schéma que la base de production qui, elle, n'utilise pas les mêmes paramètres de connexion. Ces informations seront spécifiées dans le fichier `databases.yml` (voir ci-dessous). 
    8588 
    8689=== La syntaxe de base pour le schéma === 
    104107Pour toutes ces colonnes vous n'avez pas à spécifier leur type. Symfony déduit leur format à partir de leur nom. C'est pour cette raison que le fichier `schema.yml` est si facile à écrire. 
    105108 
     109 
    106110== Les fichiers du modèle de données objet == 
    107111 
    111115 
    112116{{{ 
    113 $ symfony propel-build-model 
     117 $ symfony propel-build-model 
    114118}}} 
    115119 
    117121 
    118122{{{ 
    119 $ pear install http://phing.info/pear/phing-current.tgz 
     123 $ pear install http://phing.info/pear/phing-current.tgz 
    120124}}} 
    121125 
    123127 
    124128{{{ 
    125 BaseArticle.php  
     129 BaseArticle.php  
    126130 BaseArticlePeer.php  
    127131 BaseComment.php 
    132136 
    133137{{{ 
    134 Article.php  
     138 Article.php  
    135139 ArticlePeer.php  
    136140 Comment.php 
    138142}}} 
    139143 
    140 Vous n'avez défini que deux tables et vous vous retrouver avec huit fichiers. Pourquoi donc ?? 
     144Vous n'avez défini que deux tables et vous vous retrouver avec huit fichiers. 
    141145 
    142146=== Le modèle de base et le modèle courant === 
    143147 
    144 Pourquoi avoir deux version du modèle de données objet, l'un dans `model/om/` et l'autre dans `model/` ? 
     148Pourquoi avoir deux versions du modèle de données objet, l'un dans `model/om/` et l'autre dans `model/` ? 
    145149 
    146150Vous aurez certainement besoin d'ajouter vos propres méthodes et attributs aux objets du modèle (pensez à la méthode `->getName()` qui permet de joindre les champs Prénom et Nom). De même, au fil du développement de votre projet, vous aurez probablement à ajouter des tables et des colonnes. A chaque fois que vous modifiez le fichier `schema.yml`, vous devrez génerer à nouveau les classes du modèle objet, à l'aide de la commande `symfony propel-build-model`. Si vos méthodes ont été rajoutées à celles précédemment générées, elles seront alors effacées à chaque fois. 
    147151 
    148 Les classes `Base` qui se trouvent dans le répertoire `model/om/` sont celles générées par Propel. Vous ne devriez '''jamais''' les modifier, car à chaque fois que vous générez le modèle, ces fichiers seront effacés. Par contre, les classes qui se trouvent dans le répertoire `model/`, qui héritent des classes précédentes, ne sont pas réécrites. C'est donc là que vous devez ajouter vos propres méthodes. 
     152Les classes `Base` qui se trouvent dans le répertoire `model/om/` sont celles générées par Propel. Vous ne devriez '''jamais''' les modifier, car à chaque fois que vous générez le modèle, ces fichiers sont effacés. Par contre, les classes qui se trouvent dans le répertoire `model/`, qui héritent des classes précédentes, ne sont pas réécrites. C'est donc là que vous devez ajouter vos propres méthodes. 
    149153 
    150154Par exemple, voici le contenu du fichier `model/Article.php` nouvellement créé : 
    179183 
    180184D'un point de vue du modèle de données, vous noterez qu'il ne peut pas y avoir d'objet `Peer`. C'est pourquoi les méthodes se trouvant dans les classes `Peer` seront appelées avec la syntaxe `::` (pour un appel de méthode de classe) plutôt que l'habituel `->` (pour un appel de méthode d'objet). 
     185 
    181186 
    182187== Accès aux données == 
    224229 
    225230{{{ 
    226 $article->fromArray(array( 
     231 $article->fromArray(array( 
    227232    'title'   =>   'Mon premier article', 
    228233    'content' =>   'C\'est mon tout premier article.\n J'espère que vous l\'appréciez !', 
    337342}}} 
    338343 
     344 
    339345== Configuration de l'accès à la base de données == 
    340346 
    342348 
    343349{{{ 
    344 prod: 
     350 prod: 
    345351   propel: 
    346352     param: 
    380386 
    381387{{{ 
    382 all: 
     388 all: 
    383389   propel: 
    384390     class:          sfPropelDatabase 
    392398 
    393399{{{ 
    394 all: 
     400 all: 
    395401   propel: 
    396402     class:          sfPropelDatabase 
    399405}}} 
    400406 
     407 
    401408== Syntaxe de schéma étendu == 
    402409 
    408415 
    409416{{{ 
    410 propel: 
     417 propel: 
    411418   _attributes:   { noXsd: false } 
    412419}}} 
    415422 
    416423{{{ 
    417 propel: 
     424 propel: 
    418425   _attributes:   { defaultIdMethod: none } 
    419426}}} 
    422429 
    423430{{{ 
    424 propel: 
     431 propel: 
    425432   blog_article: 
    426433     _attributes: { phpName: Article } 
    430437 
    431438{{{ 
    432 propel: 
     439 propel: 
    433440   blog_article: 
    434441     _attributes: { isI18N: true, i18nTable: db_group_i18n } 
    440447 
    441448{{{ 
    442 propel: 
     449 propel: 
    443450   blog_article: 
    444451     id:                 # laissons symfony faire le travail 
    449456 
    450457{{{ 
    451 propel: 
     458 propel: 
    452459   blog_article: 
    453460     id:       { type: integer, required: true, primaryKey: true, autoincrement: true } 
    475482 
    476483{{{ 
    477 propel: 
     484 propel: 
    478485   blog_article: 
    479486     id:                 
    505512 
    506513{{{ 
    507 propel: 
     514 propel: 
    508515   blog_article: 
    509516     id:                 
    522529 
    523530{{{ 
    524 id:         { type: integer, required: true, primaryKey: true, autoincrement: true } 
     531 id:         { type: integer, required: true, primaryKey: true, autoincrement: true } 
    525532 foobar_id:  { type: integer, foreignTable: db_foobar, foreignReference: id } 
    526533 created_at: { type: timestamp } 
    537544 
    538545{{{ 
    539 propel: 
     546 propel: 
    540547   db_group: 
    541548     id:          - 
    548555 
    549556{{{ 
    550 propel: 
     557 propel: 
    551558   db_group: 
    552559     _attributes: { isI18N: true, i18nTable: db_group_i18n } 
    566573 
    567574{{{ 
    568 [xml] 
     575 [xml] 
    569576 <?xml version="1.0" encoding="UTF-8"?> 
    570577  <database name="propel" defaultIdMethod="native" noxsd="true"> 
    594601Symfony peut lire les schémas écrits au format XML. Si votre schéma est trop complexe pour la syntaxe YAML, si vous avez déjà un schéma au format XML, ou si vous connaissez déjà Propel et que vous ne souhaitez pas réécrire votre schéma en YAML, il vous suffit de mettre votre fichier `schema.xml` dans le répertoire `config/` de votre projet, puis de construire le modèle. 
    595602 
     603 
    596604== Ne créez pas deux fois le modèle == 
    597605 
    601609 
    602610{{{ 
    603 $ symfony propel-build-sql 
     611 $ symfony propel-build-sql 
    604612}}} 
    605613 
    611619 
    612620{{{ 
    613 $ mysqladmin -u root -p create blog 
     621 $ mysqladmin -u root -p create blog 
    614622$ mysql -u root -p blog < data/sql/schema.sql 
    615623}}} 
    628636 
    629637{{{ 
    630 $ symfony propel-build-schema 
     638 $ symfony propel-build-schema 
    631639}}} 
    632640 
    636644 
    637645{{{ 
    638 $ symfony propel-build-schema xml 
     646 $ symfony propel-build-schema xml 
    639647}}} 
    640648 
    641649Plutôt que de générer un fichier `schema.yml`, cette commande va créer un fichier `schema.xml`, compatible avec Propel, qui contiendra les informations relatives au type de la base. Soyez conscient que les schémas XML générés de la sorte tendent à être assez chargés et difficile à lire. 
    642650 
     651 
    643652== Bases de données multiples == 
    644653 
    648657 
    649658{{{ 
    650 //dans le fichier blog_schema.yml 
     659 //dans le fichier blog_schema.yml 
    651660 blog: 
    652661   table1: 
    660669}}} 
    661670 
     671 
    662672== Refactoriser la couche de données == 
    663673 
    680690Déplacer le code dans un endroit plus approprié est l'une des techniques de refactorisation. Si vous le faites souvent, votre code sera plus facile à maintenir et à comprendre des autres développeurs. Une bonne règle de conduite pour savoir quand effectuer une refactorisation vers la couche de données, c'est lorsque le code d'une action compte plus de dix lignes de code PHP. 
    681691 
     692 
    682693== Propel dans symfony == 
    683694