Avec le Zend Framework, nous pouvons évidemment gérer les requêtes et les transactions SQL . Mais ce qui est pratique avec ce framework, c’est la façon de gérer cela.
Au lieu d’écrire la requête brut de pomme, comme normalement avec PHP, nous pouvons utiliser un objet qui va préparer la requêtes SQL à exécuter.
Tout d’abords commençons par réaliser le modèle. Un modèle (en orienté objet) correspond à un élément dans la base de donnée. Par exemple, nous avons une table users dans notre base de donnée, le modèle correspondant est alors une classe User qui correspond à un enregistrement dans la base de donnée.
class User extends Zend_Db_Table
{
protected $primary = "user_id";
public function __construct($userId)
{
// On prépare ici la requête SQL et on ne l'exécute pas
$select = $this -> select() -> from('users',array('user_id','lastname','firstname'))
-> where('user_id = ? ',$userId)
-> where('actif = 1');
/*
Comme vous pouvez le voir, on chaine les appels avec PHP et donc on creer
notre requête SQL à partir des méthode de la classe.
Correspondance SQL :
SELECT user_id, lastname, firstname FROM users WHERE user_id = ? AND actif = 1
*/
// et ensuite on exécute la requête SQL
$result = $this ->fetchRow($select);
}
}
Bien évidemment, nous pouvons géré les clause JOIN, OR WHERE , ORDER et plein de petit plus à voir ici.
En plus, comme je vous l’ai montré, plus besoin d’échapper les caractère pour éviter les injections SQL vu que le code PHP de Zend le fait tout seul.
Je vous conseille d’utiliser cette méthode qui est vraiment très pratique pour de courtes requêtes SQL.
« [Sondage] Vous préférez les articles ou les screencasts | Un outils de développement pour internet explorer 8 à la sauce de Firebug »
Aucun trackback
5 commentaires
Victor Nicollet
22 septembre 2008 à 9:56
1Attention: si tu appelles « modèle» les tables, tu tombes dans l’Anemic Domain Model Antipattern. Dans un design orienté transactions (qui en soi n’est pas du tout quelque chose de mal) c’est normal que tes tables soient ton modèle. Dans un design orienté objet, on choisit d’associer au modèle (en plus des données représentées dans la table) des fonctions correspondant au domaine fonctionnel du modèle. Par exemple, une base de données ne peut pas vérifier qu’un champ est un e-mail, mais un modèle orienté objet le vérifie.
http://www.martinfowler.com/bliki/AnemicDomainModel.html
Victor Nicollet
22 septembre 2008 à 10:02
2Ah, et pour m’apprendre à répondre trop vite… tu dis que User représente un enregistrement. Mais la ligne « class User extends Zend_Db_Table» me dit que c’est une table, et non un enregistrement (et c’est peu crédible qu’un objet soit à la fois une table et un enregistrement de cette table).
http://nicollet.net/index.php?option=com_content&view=article&id=17:inheritance
C’est des petits rien comme ça que tu regretteras inévitablement lorsque tu voudras étendre la table que User utilise.
Arrangeur
26 octobre 2008 à 22:29
3Coucou me(ci pour ce billet ! Il est super ton design, qui et-ce qui l’a fairt ?
Korri
30 octobre 2008 à 15:14
4Il me semble que la requete crée serais plutôt :
SELECT user_id, lastname, firstname FROM users WHERE user_id = ? AND actif = 1
et pas
SELECT id, lastname, firstname FROM users WHERE user_id = ? AND actif = 1
Clément
30 octobre 2008 à 16:39
5@Arrangeur: De rien ! Oui c’est moi qui ai fait le design
@Korri: En effet, je corrige ca dans le minute ! Bienvenue sur dator.fr
Laisser un commentaire
Devenir Fan de Dator.fr
Nuage de tags
Sponsors
Blogoliste
Blogs Amis
Derniers Posts
Derniers Commentaires
Les meilleurs sujets
Propulsé par WordPress