Zend Framework contient déjà tout le nécessaire pour accéder à de nombreuse base de données. Je vais aborder ici son utilisation. La littérature sur la connexion à une base est suffisamment dense pour que je considère que celle-ci est déjà faite. Je vais donc me concentrer sur l’accès aux données et leurs manipulations.
Approche conceptuelle
Une base de données est avant tout un gisement organisé de données structurée. Que ce soit une base de donnée relationnelle ou un annuaire, ou encore un fichier de donnée structurée, on se trouve devant deux notion fondamentales. Une collection et des éléments de cette dernière. Dans une base de données les collections sont appelées Tables et les éléments Rows. Une base de donnée relationnelle peut comporter bien d’autre objets mais dans sont fondement elle est constituée de Tables qui contiennent des Rows. Cette séparation distincte de ces deux éléments et primordiale pour obtenir une conception claire de son application. En effet n ne fait pas les mêmes opérations sur une table que sur un row. En même temps on voit que ces deux types d’objet sont intimement liés.
La représentation Objet
Zend Framwork nous fournit deux classe pour représenter ses éléments. Il s’agit de Zend_Db_Table_Abstract et Zend_Db_Table_Row_Abstract. Comme leur nom l’indique ces classes étant abstraites, ne sont pas utilisables directement. Pour aller au plus simple ZF fournit aussi un classe Zend_Db_Table dérivant de Zend_Db_Table_Abstract qui par simple instanciation permet de manipuler une table. Cette classe fournit déjà pas mal de possibilités mais on peut constater qu’il n’existe pas de classe pour les row correspondante. Simplement parce que de façon très générales un classe Zend_Db_Table_Row ne comporterait rien de particulièrement intéressent. En effet les opérations que l’on peut faire sur un row dépendant complètement du type de données qu’il contient. Et a priori il peut s’agit de n’importe quoi.
Approche par dérivation
Si on définit des classe abstraite c’est pour qu’elles soient dérivées en classes concrètes. Et si les concepteurs de ZF s’en sont donné la peine ce n’est surement pas pour la beauté de la chose. Que peut nous apporter la dérivation des classes Zend_Db_Table_Abstract et Zend_Db_Table_Row_Abstract ? La première chose que nous apporte la dérivation c’est d’associer une classe drivée de Zend_Db_Table_Abstract à une table particulière de notre base. Par exemple Client_Table lié à la table client de la base. Pour cela il suffit de très peut de chose
Class Client_Table extends Zend_Db_Table_Abstract {
protected $_name = 'client';
}
Après instanciation de cette classe un appel aux méthodes de consultation de la table remontera des rows de la table client.
Ces dernier étant les objets qu’est sensé manipuler mon modèle. La conception de mon application m’a normalement amené à la manipulation de clients et donc un ensemble de méthode pour parvenir à me fins. Mais ainsi définit ma Client_Table me retourne juste des données. Il serait intéressant qu’elle me donne des objets clients c’est justement ce que permet la dérivation de Zend_Db_Table_Row_Abstract.je peux ainsi définir ma classe
Class Client_Row extends Zend_Db_Table_Row_Abstract {
}
J’ai donc une classe pour mes clients à la quelle je vais pouvoir attacher les méthodes que ma conception ma permit de définir. Reste à associer la classe Client_Table à la classe Client_Row cela se fait très simplement.
Class Client_Table extends Zend_Db_Table_Abstract {
protected $_name = 'client';
protected $_rowClass = 'Client_Row';
}
Je bénéficie maintenant de tous les méthodes de manipulation de ma table définit par ZF et à chaque fois que je récupère un row j’ai entre mes mains un client qui possède toutes les méthodes de manipulation de celui-ci.
le lien inverse
On vient de voir que la classe Client_Table et en relation avec la classe Client_Row en ce sens que tout row sortit de la table est un Client_Row. Mais qu’en est-il dans l’autre sens ? La réponse est La relation existe aussi. Intrinsèquement, la classe Client_Row connait la table qui à donné naissance à ses instances. En clair chaque Client_Row sortit d’une instance de Client_Table contient un référence à cette instance.
Il devient alors simple d’accéder à la table depuis le row. On peut se demander pourquoi. Simplement pour se faciliter la vie.
//trouver l’enregistrement client d’id 25
$aclient = $clientTable->find(25);
$aClient->maMethode();
$aClient->save();
Ce n’est qu’une facilité on pourrait très bien en repasser par une instance de la table pour faire cette mise à jour. Mais le client ayant sa propre instance de la table pourquoi ne pas en profiter. ZF a d’ailleurs prévu cela et fournit la méthode save et quelques autres.
On le voit il n’est pas bien compliqué d’utiliser la table à partir du row.
Et l’ajout de donnée ?
Si je crée une instance de Client_Row directement je n’aurais pas associé la table à mon nouvel objet. J’aurais bien toutes les méthodes définies mais je ne pourrais mettre mon objet en base sans en passer par une instance de la table. Pour recréer se lient on peut, soit, passer part la méthode setTable, soit par le tableau de paramètre du constructeur. Personnellement j’ai l’habitude de demander mes rows à la Table pourquoi ne pas demander les nouveaux rows à la table.
Class Client_Table extends Zend_Db_Table_Abstract {
protected $_name = 'client';
protected $_rowClass = 'Client_Row';
/**
* Make new row associated to this table.
*
* @param StdClass|array $obj OPTIONAL object to cast
* @return Fast_Db_Row
*/
public function newRow($obj = null) {
if ($obj)
{
if (is_object($obj))
$obj = get_object_vars($obj);
$row = $this->createRow($obj);
} else {
$row = $this->createRow();
}
return $row;
}
}
Ainsi j’ai le même fonctionnement que précédemment.
//Créer un nouvel enregistrement client.
$aclient = $clientTable-> newRow();
$aClient->maMethode();
$aClient->save();
Est-ce tout ?
Nous venons de voir que cette approche permet de faire un mapping d’une classe issue de ma conception sur les enregistrements d’une table de ma base. ZF offre au passage toute la manipulation des relations. Et toutes les fonctionnalités de manipulation des données sur de la table ajout, mise à jour, suppression. Mais cette approche permet aussi d’enrichir cette couverture déjà riche de méthode spécifique à notre modèle de données. Ainsi la classe Client_Table peut être enrichie de toutes les méthodes qui me sont nécessaire et qui doivent me retourner un Client_Row. J’ai un réceptacle naturel pour toutes les requêtes qui retourne un ou des client_Row mais aussi des données ayant rapport direct avec la table client.
Par exemple la méthode getBoutiqueList qui me retourne la liste des noms de boutique trouve sa place dans Boutique_Table.
Je bénéficie au passage d’un nettoyage automatique des champs de mes objets. Il arrive parfois qu’on associe des valeurs à l’ensemble des données d’un formulaire pour se simplifier la vie. Si je donne tous ses champs de formulaire à la méthode newRow mon objet ne contiendra que les valeurs correspondant à un champ de la table les autres étant supprimé au passage. Notez que si vous utilisez des tableaux de donnée à la place d’objet la méthode createRow est là pour vous. De même pour obtenir le tableau des données d’un objet métier vous avez la méthode toArray. Pour ma part j’ai ajouté la méthode toStdClass pour obtenir un objet standard qui est parfois intéressant (pour la mise en session par exemple).
Restrinction d’accès
Les ACL permettent de restreindre l’accès aux fonctionnalités de votre application. Pour restreindre l’étendu des données il est nécessaire d’en passer par des restrictions sur les requêtes. Il est parfaitement possible d’intégrer cette restriction dans la table elle-même
Class Client_Table extends Zend_Db_Table_Abstract {
protected $_name = 'client';
protected $_rowClass = 'Client_Row';
/**
* Restriction for query
* @var string
*/
protected $_restrict = array('cli_level > 0');
public function __construct($config = array())
{
parent::__construct($config);
$user = Zend_Auth::getInstance()->getIdentity();
if ($user) {
$this->_restrict[] = 'cli_group IN
(SELECT grp_id FROM group WHERE usr_id = '.$user->usr_id.')';
} else {
//sans identité on ne peut rien voir dans la base
$this->_restrict = 'false';
}
}
/**
* Fetches one row in an object of type Zend_Db_Table_Row_Abstract,
* or returns Boolean false if no row matches the specified criteria.
*
* @param string|array $where OPTIONAL An SQL WHERE clause.
* @param string|array $order OPTIONAL An SQL ORDER clause.
* @param boolean $restrict OPTIONAL use restrict SQL clause.
* @return Fast_Db_Row The row results per the
* Zend_Db_Adapter fetch mode, or null if no row found.
*/
public function fetchRow($where = null,
$order = null,
$restrict = true)
{
if ($restrict&&
isset($this->_restrict)&&
is_string($this->_restrict))
{
if (is_array($where))
{
$where[] = $this->_restrict;
} else {
$where = '('.$this->_restrict.') AND ('.$where.')';
}
} elseif ($restrict&&
isset($this->_restrict)&&
is_array($this->_restrict))
{
if (is_array($where))
{
$where = array_merge($where, $this->_restrict);
} else {
foreach ($this->_restrict as $contraint) {
$where = '('.$contraint.') AND ('.$where.')';
}
}
}
$res = parent::fetchRow($where,$order);
return $res;
}
/**
* Make new row associated to this table.
*
* @param StdClass|array $obj OPTIONAL object to cast
* @return Fast_Db_Row
*/
public function newRow($obj = null) {
if ($obj)
{
if (is_object($obj))
$obj = get_object_vars($obj);
$row = $this->createRow($obj);
} else {
$row = $this->createRow();
}
return $row;
}
}
Ainsi lorsqu’on fait appel à une méthode d’extraction de données sur la table la restriction s’applique automatiquement. Notez que j’ai prévu de pouvoir débrailler cette restriction avec le paramètre supplémentaire $restrict cela peut parfois s’avérer utile.
Conclusion
Cette approche conceptuelle permet facilement de coller la conception en classe sur son modèle de donnée. Elle permet un découpage logique de la partie métier de son application. Mais elle ne résous pas tout. Il reste en effet des requêtes qu’on ne sait pas toujours où placer. Mais les possibilités d’extensions de ses classes est grand et laisse libre court à votre imagination.
A+JYT