Accès à la base de données: Zend_Db
By Geoffrey on Thursday 31 August 2006, 18:08 - Coding - Permalink
Arrive fatalement un moment dans un projet où le besoin d'attaquer sauvagement une base de données se fait sentir. Peu importe le SGBD utilisé, les besoins de base sont souvent les mêmes et se résument bêtement a ce que certains appellent les CRUD actions, c'est à dire Create, Read, Update, Delete. Le Zend Framework fournit une méthode simplissime pour gérer ces actions basiques, et des facilités pour gérer des opérations plus avancées. Prenons pour exemple une table contenant les informations des membres d'un site, que nous appellerons members (comme c'est original), et qui ne contiendra pour le moment que quelques champs (dont les noms seront, j'espère, assez explicite): mail, password et created_on.
Configuration de Zend_Db
Pour commencer, il nous faut configurer Zend_Db. Rien de plus simple, cette classe possède une méthode factory qui accepte deux arguments: le type de base de données à utiliser, et un tableau de paramètres. Il faut ensuite spécifier à Zend_Db_Table que nous souhaitons utiliser cette instance précise de Zend_Db.
$params = array(
'host' => 'localhost',
'username' => 'root',
'password' => 'someobscurepassword',
'dbname' => 'myappname'
);
$db = Zend_Db::factory('PDO_MYSQL', $params);
Zend_Db_Table::setDefaultAdapter($db);
Opérations CRUD de base
Il suffit d'étendre la classe Zend_Db_Table pour obtenir un Modèle spécifique à notre table de membres:
class Members extends Zend_Db_Table {
}
C'est tout ? Oui, c'est tout. Une fois ceci fait, nous pouvons manipuler la table très simplement, par exemple, pour insérer une ligne:
$member = new Members;
$data = array(
'mail' => 'geoffrey@nevra.net',
'password' => md5('password'),
'created_on' => date('Y-m-d H:i:s'),
);
$member->insert($data);
En plus de la méthode insert, Zend_Db_Table implémente les méthodes update et delete, ainsi que find, qui s'utilisent ainsi (en admettant que le champs mail soit déclaré comme étant la PRIMARY KEY de la table):
$member = new Members;
$db = $member->getAdapter();
$where = $db->quoteInto('mail = ?', 'geoffrey@nevra.net');
$data = array(
'password' => md5('other_password'),
);
$row = $member->find('geoffrey@nevra.net');
$member->update($data, $where);
$member->delete($where);
Voilà pour les fonctionnalités de base, nous verrons une prochaine fois comment étendre les fonctionnalités de Zend_Db_Table pour, entre autres, automatiser certaines taches :-)
Comments
ça paraît vraiment simple une fois l'article lu :)
Merci pour cet article.
C'est en lisant ça que je me dis que je préfère vraiment RoR...
Pour la création de model, c'est pareil (sauf qu'il existe un generator simple pour "préfaire le fichier", ensuite, je pourrai faire ça :
Je ne parle même pas de la gestion des paramètres envoyés par GET/POST.
Salut, je suis encore un néophyte en php et encore plus en objet. Mais le zf m'interesse pas mal, pour des raisons similaires aux tiennes - au passage, je remarque que tu es assez prolifique sur le sujet et je t'en remercie car la doc "pratique" sur le sujet n'est pas trés variée (mais ça avance).
Voilà, les présentations étant faites, venons-en à ce qui me turlupine...Zend_Db_Table. Lors de mes tests je me suis satisfait de Zend_db pour les CRUD actions. La seule différence étant que la méthode requiert le nom de la table: $db->insert('members',$data);
MAIS...comme je n'aime pas passer pour un ane et que j'ai bien lu ton billet, je suis retourné dans las doc de Zend_Db_Table pour voir les méthodes supplémentaires proposées et ... je me dis que j'aurai peut-être du attendre le suite pour la ramener. Il n'empéche, ce qui me géne c'est une classe par table. Ca colle pas trop avec l'impression que me donne la POO jusqu'à maintenant. Je verrais plus des extensions de méthodes dans Zend_Db.
Bon, le newbie a parlé...et il va attendre la suite de ton article - avec impatience - pour savoir si l'ane qui sommeille en lui s'est réveillé.
Au contraire, dans le plus pur style objet, tu associes une classe à une table, on peut appeler ça de différentes manières, moi j'appelle ça du mapping (PEAR appelle ça des DataObject par exemple, cf PEAR::DB_DataObject).
C'est philosophiquement correct, puisqu'une classe = un objet, et que en théorie, si ton design SGBD n'est pas complètement vrillé, une table = un objet également (un objet membre, un objet news, etc).
D'un point de vue plus pragmatique, avoir une classe pour chaque table peut sembler lourd et inutile tant que tu te contentes des actions CRUD de base, mais tu verras dans un prochain article qu'en fait c'est une manière très utile de procéder :-)
Un objet par ligne (une classe par table) s'appelle ActiveRecord
Ok, merci pour vos infos ... quelques lignes qui suffisent à m'éclaicir les idées, d'autant qu'entre-temps je me suis penché sur Zend_Db_Table_Row et consorts et que ça colle avec ce que j'ai en tête.
Au passage, j'espère que tu as des retours s'agissant de ton idée de blog collaboratif fracophone. C'est le bon moment pour un sujet qui me semble promis à un bel avenir ... tant que le zf en aura un. Mais je ne me fais pas trop de soucis sur ce point ... ils sont tout excités sur le site d'ibm