Discussion :

[ovh]

Bonjour,

Dans cet article je vous propose de voir comment intégrer des composants PHP modernes dans une application « legacy » écrite en Zend Framework 1 grâce à Composer et au conteneur d'injection de dépendances de Symfony2.

http://ovanhoof.developpez.com/tutor...poser-symfony2

A vos commentaires et bonne lecture

[Tsilefy]

Hello!

Pourquoi utiliser en plus UniversalClassLoader alors que Composer fait très bien l'autoloading des classes?

[ovh]

Pourquoi utiliser en plus UniversalClassLoader alors que Composer fait très bien l'autoloading des classes?

Pour charger le namespace de nos classes de service, d'entités etc. dans /library/App, sinon ZF ne retrouve pas nos classes
Composer est en effet suffisant pour les libs dans /vendor, mais il ne s'occupe pas de nos classes métier dans /library/App.

[Tsilefy]

Composer peut charger toutes les classes, qu'elles soient sous PSR-0, PSR-4, classmap ou même des fichiers spécifiquement indiqués (ex: fichiers de fonctions).

Le seul souci avec classmap est que les nouveaux fichiers ne sont chargées que si on fait un dump-autoload (c'est peut-être ce qui bloque ici), mais si les classes sont PSR-0 ou PSR-4 il n'y a aucun souci.

[ovh]

Ah il faudra que je teste ça à l'occasion alors
Si ça peut soulager l'appli d'une dépendance inutile, c'est toujours ça de gagné !

[ovh]

J'ai enfin pris le temps de faire la modif, toutes les classes sont désormais chargées avec Composer, article mis à jour !

[Tsilefy]

Formidable! Merci pour ce super article!

[vermine]

Bonjour à tous,

Suite à une remarque pertinente d'un lecteur, l'auteur (Olivier Van Hoof) a mis l'article à jour. C'est désormais Composer qui gère l'autoload des classes de services.

N'hésitez pas à lire, voire relire, cet article sur la manière d'intégrer des composants PHP modernes à un projet à base de Zend Framework 1 et de Symfony2.

Moderniser une application PHP Zend Framework 1 avec le conteneur de dépendances de Symfony2

[vincentclair]

Article très intéressant, et qui tombe à pic pour nos besoins.

En revanche, il y a une chose qui m'a surpris, c'est la description du dossier "library/App/Domain" : je suis pas encore expert en DDD, je pratique seulement depuis peu cette méthode : à mon avis, on ne devrait pas parler de base de données. Ce répertoire est sensé être complètement indépendant dans toute infrastructure (base de données, mais aussi envoie de mail ou ldap comme c'est très bien précisé dans la description de l'infra).
- Dans mon répertoire Domain, je ne met généralement que les modèles, les fameux POPO, avec des interfaces pour les Repository, ainsi que les services.
- Dans le dossier infrastructure, je vais mettre en place la configuration Doctrine et les Repository implémentant les interfaces précédemment citées.

Une autre petite note également sur les annotations de Doctrine. Je pense que ce n'est pas une bonne pratique, puisqu'en les utilisant, les modèles sont fortement liés à Doctrine. La séparation des 3 couches n'est donc pas optimales à mon sens. Si on doit justement faire évoluer l'infra, le travail sera plus difficile (bon, jusqu'à présent, qui a du changer d'infra ? C'est très rare, je l'accorde )

[ovh]

La structure de répertoires proposée n'est pas du DDD pur, c'est juste inspiré par le DDD Le but de l'article est juste de montrer comment créer et charger des services

Attention cependant avec les design patterns, le danger c'est de faire de l'over-engineering... Un excès d'architecture qui va empiler les couches inutilement et rendre le code inmaintenable... Tout est affaire d'équilibre