Zend FR

Zend_Db_Table_Abstract est comme son nom l'indique une classe abstraite. elle représente au sens large une table d'une base de donnée.  mais comme elle est abstraite on ne peu l'utiliser telle quelle

pour l'utiliser il faut définir une classe concrète
par exemple j'ai une table client dans ma base je vais avoir besoin d'objet dans mon appli pour représenter la table dans le système ces objets seront des instance d'une classe qui prends en compte les particularités de la table client et qui est une représentation de la table client de la base cette classe dérivera donc de Zend_Db_Table_Abstract
Model_Cient_Table extends Zend_Db_Table_Abstract la définition de cette classe prendra en charge toute les caractéristique de la table client et on fera ainsi pour toutes les table de la base que l'on veut représenter.

mais il arrive souvent que les besoin sur certaine table soient minime et que les particularités des table en question soient faibles. devoir créer une classe la charger et l'instancier pour toutes ces tables peut devenir pénible. Zend a pensé à nous avec Zend_Db_Table cette classe dérive de  Zend_Db_Table_Abstract mais elle est concrète. à priori elle n'est pas en phase avec une table quelconque de la base. elle propose donc des méthode pour que chaque instance puise se mettre en relation avec une Table de la base. elle offre au passage la prise en charge de quelque particularité (de façon dynamique) mais elle n'offre pas toute la souplesse d'une classe dédiée. en contre partie elle est directement utilisable pour de nombreuse table de la base.

la question a se poser est dois-je ou pas créer une classe dédier. et là c'est la conception de l'application qui peu apporter une réponse. car les deux options sont toujours possible et leur coût respectif peut en fonction des circonstance pencher d'un coté ou de l'autre.

voilà pour ce qui est de Z_D_T maintenant le mapping
à la base ZF propose une approche simple un objet Z_D_T représente une table telle qu'elle est définie dans la base. c'est a dire que les objets enregistrements obtenus à partir de l'objet Z_D_T auront exactement les même champs que ceux qui sont présent dans la table. c'est du un à un

comment dans ses conditions mapper un objet metier sur une partie de la table ou au contraire sur plusieurs tables ?
c'est la raison de l'introduction des classes de mapping

je n'ai pas encore étudié cette couche mais son but est de permettre au développeur de définir la relation de mapping entre l'objet Z_D_T et la table.

je ne sais pas jusqu'où cela va mais j'imagine par exemple une table facture qui contient des infos sur une facture et une table ligne de factures qui contient chaque ligne de facture.

en ayant un mappage souple je peux imaginer un objet Z_D_T qui me remonte des objets aiyant des champs en lecture seule contenant le nombre de ligne de la facture le total HT le total TTC le nombre d'objet de la facture et ce sans remonter les ligne.

pour y parvenir il faut un objet Z_D_T dédié y associer un Z_D_T_Select qui fasse les calculs et un mapping qui décrit comment gérer (lors des accès à la base) les champs remontés

A+JYT