Zend FR

Salut,

Perso c'est ce que je fait.

J'avoue ne pas avoir bien saisi :

sekaijin a écrit:

pas tout a fait le modèle doit encapsuler la couche de persistance

@++ Kaimite

ramos tu as un exemple concret de ce que pourrait contenir le mapper ? et le rapport au zend_table et zend_row ...

Salut,

J'ai regardé le code et il me vient une question bete...

Je vois souvent cette écriture

funtion getEmail () 
{
    return $this -> email;
}
...

$email = $user -> getEmail();

Pourquoi ne pas faire directement

$email = $user -> email;

Est-ce uniquement valable dans le vas ou la propriété serait private ou protected ?

Merci pour vos réponse.

Cordialement,
Kaimite

oki,

De mon coté j'utilise une méthode :

renvoyerInfosPourXXX ()
{

}

La plupart du temps c'est renvoyerInfosPourWeb() et elle me renvoi un tableau associatif avec toutes les valeurs filtrées et préparées.

Je viens de recevoir une base avec une table de 72 champs et je trouve un peu galère de devoir faire 72 méthodes :

getXXX()

D'ailleurs a ceux qui utilisent cette méthode, utilisez vous une solution "automatisée" pour ce genre de grosses table ?

Merci pour les réponses.

Cordialement,
Kaimite

oki.

Merci pour la réponse.

Je commence a mieux cerner tout ça

Encore un truc a regarder de plus près ! c'est ajouté dans la liste "à faire un jour ou l'autre"

Cordialement,
Kaimite

Dernière modification par Kaimite (19-06-2009 10:28:07)

ramos a écrit:

Salut Kaimite,

La plupart du temps, il est bon d'utiliser des attributs privés (ou protected) et mettre en place des getters-setters dès le début.
La raison, c'est que tu pourra plus tard ajouter un traitement avant de renvoyer la valeur, sans avoir à modifier toutes les classes qui font appel à l'attribut email pour ton exemple.

C'est bien la plupart du temps, c'est extrêmement utilisé en Java, mais parfois ça ne sert à rien, voire génant (exemple : pour sérialiser une classe pour la passer à un framework comme GWT ou Flex, les attributs de cette classe doivent être public).

Typiquement, pour ta table de 72 colonnes, tu n'utilises pas de getter setter pour les attributs. Si tu utilises Zend_Db_Table, tu récupères un Zend_Db_Table_Row et les colonnes sont directement accessibles (soit par $row->email, soit par $row['email']). C'est un cas où justement les getter setter ne sont pas judicieux, à mon avis.

Enfin, on parlait de mapper tout à l'heure. Ce mapper utilise une Zend_Db_Table, et là c'est judicieux de faire un getTable() dans le mapper.

Je ne sais pas comment est codé Zen_Db_* car je ne l'utilise pas.
Mais dans Doctrine, tu peux faire $row->email et $row['email'] et $row->getEmail() et $row->get('Email'). Tous les attributs sont protégés, il utilise des méthodes magiques et implémente les interfaces nécessaires au PHP. Dans tous les cas, tu peux rajouté toi-même une fonction getEmail pour faire un filtre, et donc, quelques soit la méthode que tu utilises ton getter sera utilisé comme proxy. (et encore, j'abrège la)

Kaimite a écrit:

Je viens de mettre à jour mon ZF avec la version 1.6 et j'ai testé le Zend_Paginator.

Très simple à mettre en place et à utiliser

Au niveau des requêtes ça ne change pas grand chose :

Code:

SELECT COUNT(*) AS zend_paginator_row_count FROM `tbl_articles`

SELECT `tbl_articles`.`uid` FROM `tbl_articles` LIMIT 10 OFFSET 80

En tout cas c'est très simple à mettre en place !

Bonjour,

Pour rebondir sur la question de la gestion de la pagination en minimisant l'impact des requêtes sur les performances, il existe une fonction SQL, nommée SELECT FOUND_ROWS, qui permet de calculer le nombre de résultats de la requêtes en faisant abstraction de la LIMIT posée.
Dès lors faire les requêtes suivantes ramèneront respectivement les articles désirés (LIMIT) et le nombre total d'article dans la table (sans devoir faire une requête lourde qui compte tous les articles (COUNT(*)) :

SELECT SQL_CALC_FOUND_ROWS `tbl_articles`.`uid` FROM `tbl_articles` LIMIT 10 OFFSET 80;
SELECT FOUND_ROWS() AS zend_paginator_row_count;

Kaimite a écrit:

Je viens de mettre à jour mon ZF avec la version 1.6 et j'ai testé le Zend_Paginator.

Très simple à mettre en place et à utiliser

Au niveau des requêtes ça ne change pas grand chose :

Code:

SELECT COUNT(*) AS zend_paginator_row_count FROM `tbl_articles`

SELECT `tbl_articles`.`uid` FROM `tbl_articles` LIMIT 10 OFFSET 80

En tout cas c'est très simple à mettre en place !

une petite note au passage puisqu'on parle d'optimisation.
il faut éviter autant que ce peut les *
et particulièrement sur un COUNT. sur un count ça ne sert à rien de compter les élément de toutes les colonnes vu qu'on compte les lignes.

en faisant juste un peu de sémantique on comprends mieux.
SELECT COUNT(*) signifie COMPTER (TOUTE LES COLONNES)  pour chaque Ligne
alors que
SELECT COUNT(1) signifie COMPTER (1) pour chaque ligne

Les moteur moderne s'en sortent pas trop mal mais dans leur analyse les moteurs vont avec le * prévoir de remonter toutes les colonnes pour compter les lignes (en général il optimisent après car ils s'aperçoivent que les colonnes ne sont pas utilisées) alors qu'un COUNT(1) ne vas utiliser qu'une seule fois la constante 1 donc pas de remonté de colonne à priori et pas d'optimisation sur les colonnes
si sur les requête simple select count l'impact n'est souvent pas très pertinent il est étonnant de voir le comportement de certain moteur lorsque on place des cout dans des requêtes plus complexes contenant des group by et des sous requêtes.

A+JYT

Effectivement le SQL_CALC_FOUND_ROWS n'est pas générique et implémenter des méthodes d'abstraction dans ce sens serait un nouveau petit plus dans la performance.

Dans l'article relatif à COUNT, il est surtout mis en évidence que faire un COUNT() sur une colonne non-indexée (ou indexée mais couplée) est plus lent qu'un COUNT(*).
Ce que je retiens de cet article (commentaires entre autres) et d'articles connexes, c'est que COUNT(1) est toutefois plus rapide sur la majorité des SGBD car il ne parse pas toutes les colonnes des lignes pour le dénombrement. (et un COUNT() sur une colonne indexée NOT NULL reste mieux qu'un COUNT(*) toutefois).

Dernière modification par Eureka (19-07-2009 16:58:14)