Zend FR

stephane · 27-04-2007 18:00:01

Je voulais vous soumettre cette réflexion afin d'avoir votre avis sur ce sujet un peu particulier. Dans un fichier Php, il existe à ma connaissance deux façons d'importer un autre fichier (et donc une classe). La première solution consiste à faire appel à l'instruction include() :

Code:

<?php
  include 'Users.php';
  
  class UserDao {
    public function findAll() {
      $user = new Users();
      ...
?>

Il faut également considérer toutes ses variantes, à savoir include_once(), require() et require_once() :

Code:

<?php
  require_once 'Users.php';
  
  class UserDao {
    public function findAll() {
      $user = new Users();
      ...
?>

Mais avec Zend Framework, il est possible de pratiquer de l'autoloading. De cette manière, il n'est même plus nécessaire de déclarer ces imports :

Code:

<?php
  class UserDao {
    public function findAll() {
      $user = new Users();
      ...
?>

Bien sûr, il faut avoir préalablement enregistré le loader de ZF dans son fichier bootstrap :

Code:

<?php
  // Includes framework loader class
  require_once("Zend/Loader.php");
  
  // Registers the loader class to get ride of imports
  spl_autoload_register(array('Zend_Loader', 'autoload'));
      ...
?>

Donc, tout va bien dans le meilleur des mondes. Plus besoin de se soucier des imports, il n'y a plus qu'à coder. Il existe probablement un problème de performance lié à l'utilisation de ce mécanisme, mais je n'ai rien lu qui le prouve à 100% (d'autant plus que grâce à lui, les classes ne sont importées que lorsqu'elles sont réellement utilisées).

Mais en contrepartie, il faut nommer ses classes Php d'une certaine manière (en suivant la convention de nommage de Pear) afin que Zend Framework puisse les retrouver et les importer. Php ne dispose malheureusement pas d'espaces de nommage, et lorsqu'on veut mettre au point une architecture (et donc une arborescence de fichiers) complexe, on se retrouve avec des noms de classes à rallonge :

Code:

<?php
  class Application_Business_Services_User_Db_UserDao {
    public function findAll() {
      $user = new Application_Business_Services_User_Db_Users();
      ...
?>

En effet, mes fichiers UserDao.php et Users.php se trouvent dans le répertoire suivant :

Code:

  \Application\Business\Services\User\Db

Je me retrouve donc avec un mécanisme d'import bien pratique mais qui nécessite une syntaxe plutôt lourde. J'en viens donc à ma question : le jeu en vaut-il la chandelle ?

Je suis en train de réfléchir à cette problématique et je pense abandonner ce mécanisme d'autoloading. Je serai alors obligé de rajouter des includes en haut de chaque fichier, mais mes noms de classes n'auront plus besoin d'être aussi compliqués. Par ailleurs, j'ai également l'impression que cela risque d'améliorer grandement l'auto-complétion dans Eclipse PDT, ce qui n'est pas négligeable.

Qu'est-ce que vous pensez de tout ça ? J'ai peut-être raté un point important ? Comme faites-vous dans vos projets Zend Framework ?

Julien · 27-04-2007 18:54:05

Très bonne remarque, Fabien Potencier ( developpeur du Framework Symfony ) en avait parlé à sa conférence ( dont la vidéo sera bientot disponible ). C'est vrai que cette syntaxe est directement liée à l'arborescence du site; et il l'avait grandement critiqué ( à tort, à raison, chacun l'appréciera comme il le veut )

En théorie, c'est cool, car on voit apparaitre la notion d'espace de nommage, ou plus précisément la notion de 'package'. Cependant, c'est bizarre d'aller chercher si bas dans l'arborescence. Pour la majorité de mes projets, je ne descends pas sous 3 niveaux.
J'ai par exemple un Personne_Membre_Table, et un Personne_Membre_Rowset ( on voit bien l'héritage ).

Il faut bien se rendre compte aussi que spl_autoload_register gère un registre, et que on peut lui passer plusieurs fonctions(méthodes) d'autoload.
Il va alors chercher la classe via les autoloads suivant la règle FIFO ( à confirmer ).

Code:

<?php
spl_autoload_register(array('ALoader', 'load'));
spl_autoload_register('anotherLoader');
$anObject = new AClass();
?>

Dans ce code, la classe Aclass() est autoloadée d'abord via le gestionnaire 'load' de la classe 'ALoader'. Si ce gestionnaire échoue dans le chargement, il passe la main au suivant : 'anotherLoader', qui s'il échoue, renverra une erreur de classe non trouvée.

Il est donc possible d'ajouter sa propre logique d'autoload à la suite de la logique de ZF.
Le tout étant de ne pas se perdre après, surtout sur un projet bossé à plusieurs ;-)

philippe · 27-04-2007 20:03:18

Personnellement, je n'utilise pas l'autoloading parce que si on veut réutiliser le code sur un site pas en autoloading, c'est le bordel. Ca m'embête d'imposer à tous mes sites d'être en autoloading.

Sinon en général on utilise plus des noms d'instance dans le code, plus que des noms de classe, j'avoue que ça ne me gène pas trop les noms à rallonge.

Sinon comme convention de nommage, j'utilise la convention des packages java :
Entreprise_Projet_MaClasse

Pour un projet toto, mes classes seront de la forme
Kitpages_Toto_Member, Kitpages_Toto_Forum,...

Et ensuite mes classes "partagées" (les classes de mon framework maison en fait) sont directement sous Kitpages : Kitpages_Log, Kitpages_Orm, Kitpages_Db...

Comme ça si j'ai une classe à refiler à quelqu'un, il n'y aura pas de conflit.

Y'a certainement d'autres approches, n'hésitez pas à envoyer la votre
A+, Philippe

Julien · 28-04-2007 00:02:04

Oui après on utilise ou pas ;-)
Coté perfs : j'ai assisté à des tests lors de conférences ( dont j'ai les vidéos mais pas les droits de diffusion ) : l'autoloading est une fonction qui impacte les performances.
Si vous n'avez pas de problèmes de perfs, houra! ; dans le cas contraire, vous verrez que la fonctionnalité d'autoload arrive le plus souvent en haut de la pile des appels les plus gourmands ( ce qui est logique quand on pense à la charge de travail que doit réaliser l'autoload, pour ceux qui veulent analyser : les sources de PHP restent dispos hein ;-) )

Pour profiler le code, je recommande l'extension XDebug ( qui fait d'ailleurs bugguer l'affichage de Zend_Debug::Dump() à cause des traitements internes de la sortie ) , avec KCacheGring ( Unix ), et [ulr=http://sourceforge.net/projects/wincachegrind/]WinCacheGring[/url], ( pour les plateformes Windows ).
C'est très simple à mettre en place, et il est interessant de pouvoir analyser les parties les plus gourmandes de son appli ;-)

stephane · 28-04-2007 12:09:18

Merci Julien et Philippe. A la vue de toutes vos remarques, je pense que je vais vraiment abandonner l'autoloading. Et du coup, les noms de classes à rallonge. A priori, il n'y a pas de problème à avoir des noms de classes sans espace de nommage si on n'utilise pas au même moment deux classes avec le même nom. Mais il n'y a pas de raison non plus pour que cela arrive si on choisit bien le nom de ses classes.

Peut-être que d'autres ont une autre vision sur le sujet ?

quode · 01-05-2007 07:57:06

Je pense effectivement qu'il vaut mieux se passer d'autoloading pour des raisons de portabilités et de performances.

stephane a écrit:
A priori, il n'y a pas de problème à avoir des noms de classes sans espace de nommage si on n'utilise pas au même moment deux classes avec le même nom. Mais il n'y a pas de raison non plus pour que cela arrive si on choisit bien le nom de ses classes

Il faut redoubler d'attention quand des classes peuvent être amenées à être loadées de manière dynamique au runtime car il est parfois difficile de prédire tous les sénarios.

stephane · 02-05-2007 17:43:20

Merci pour ton retour d'expérience quode. Je viens d'effectuer un peu de profiling avec Xdebug, et voilà ce que ça donne :

[img=http://img258.imageshack.us/img258/9275/phpautoloadingdu0.th.png]

Comme on le voit très bien dans ce récapitulatif, 71,66% du temps d'exécution du script est consacré à l'autoloading. Il s'agit en fait d'un script qui affiche une page web toute simple, sans accès à la base de données. Et bien maintenant, il ne reste plus qu'à comparer et voir ce que ça donne avec des require_once()...

quode · 02-05-2007 18:12:57

Si __autoload() est utilisée seule (sans registrer de multiple loaders différents), alors il n'y aura pas de pertes de performances par rapport à de simples include_once. Cela peut même être plus performant si le loader utilise include au lieu de include_once (ce qui semble naturel).

Un lien intéressant:
http://jokke.dk/2007/03/optimizing_php_through_habits

Je pense qu'il faut donc bien faire la part des choses entre portabilité, facilité d'utilisation et performance.

Julien · 02-05-2007 19:02:49

quode a écrit:
Je pense qu'il faut donc bien faire la part des choses entre portabilité, facilité d'utilisation et performance.

Très bon ca, il existe des "règles générales" au niveau des performances, mais évidemment il faut après traiter le cas par cas.

stephane · 02-05-2007 19:13:29

Je crois que je comprends mieux ce que tu voulais dire Julien à propos du problème de Xdebug : toutes les variables qui passent dans var_dump se retrouvent formattées en HTML (avec des tags donc). Super pratique !

Zend FR

#1 27-04-2007 18:00:01

L'import de classes et de fichiers Php : quelle stratégie choisir ?

Code:

Code:

Code:

Code:

Code:

Code:

#2 27-04-2007 18:54:05

Re: L'import de classes et de fichiers Php : quelle stratégie choisir ?

Code:

#3 27-04-2007 20:03:18

Re: L'import de classes et de fichiers Php : quelle stratégie choisir ?

#4 28-04-2007 00:02:04

Re: L'import de classes et de fichiers Php : quelle stratégie choisir ?

#5 28-04-2007 12:09:18

Re: L'import de classes et de fichiers Php : quelle stratégie choisir ?

#6 01-05-2007 07:57:06

Re: L'import de classes et de fichiers Php : quelle stratégie choisir ?

stephane a écrit:

#7 02-05-2007 17:43:20

Re: L'import de classes et de fichiers Php : quelle stratégie choisir ?

#8 02-05-2007 18:12:57

Re: L'import de classes et de fichiers Php : quelle stratégie choisir ?

#9 02-05-2007 19:02:49

Re: L'import de classes et de fichiers Php : quelle stratégie choisir ?

quode a écrit:

#10 02-05-2007 19:13:29

Re: L'import de classes et de fichiers Php : quelle stratégie choisir ?

Pied de page des forums