Foire aux questions

Ces frameworks imposent une courbe d'apprentissage assez ardue, obligeant à assimiler des concepts qui leurs sont propres.

On devient alors un développeur Sympfony (ou autre), et non plus un “développeur PHP”.

Et en même temps, les concepts simples qui devraient être gérés par le framework deviennent inutilement complexes (essayez de faire des plugins avec Symfony, vous devrez développer un event listener…).

Ces micro-frameworks peuvent sembler plus simples à mettre en œuvre de prime abord. Mais en mélangeant le routage et les contrôleurs comme ils le font, ils rendent au contraire le code moins lisible, et donc plus difficile à maintenir dans la durée.

Et pour ceux qui sont basés sur des frameworks lourds (Symfony pour Silex, Laravel pour Lumen), le reste de votre code subit toujours la lourdeur sous-jacente.

Smarty est le standard de facto des moteurs de template en PHP.

Il présente plusieurs qualités :

• Une syntaxe simple et claire, facilement assimilable par des infographistes éloignés de la logique de développement.
• Des possibilités d'extension faciles à mettre en œuvre, avec la création de filtres en PHP.
• Des performances qui peuvent être ajustées en ajoutant du cache sur des fragments de templates.

Même si la critique de Smarty semble être à la mode chez certains “penseurs” actifs dans la communauté PHP (principalement ceux qui finissent par proposer des clones de Smarty), on ne peut pas remettre en question sa très large adoption par une majorité silencieuse de cette même communauté.

Parce qu'il sera plus efficace d'utiliser PhpMyAdmin, PhpPgAdmin, PhpRedisAdmin, Adminer…

Ce n'est pas le rôle d'un framework d'offrir ce genre de fonctionnalité. Le rôle d'un framework, c'est d'offrir les bases techniques qui permettent de développer ces outils.

Les raisons invoquées pour l'utilisation d'un ORM sont habituellement :

1. Ne pas avoir besoin d'écrire de requêtes SQL.
2. Manipuler uniquement des objets.
3. Pouvoir changer de bases de données au besoin.

Voici comment Temma y répond :

1. Pour des requêtes sur une seule table, les DAO de Temma ne nécessitent pas d'écrire de requêtes SQL. Pour des requêtes plus complexes (jointures, regroupements, ...), il est toujours plus efficace d'écrire les requêtes "à la main".

   Pour pallier à leurs problèmes de performances, les ORM proposent des langages dérivés du SQL (HQL pour Hibernate, DQL pour Doctrine). Les développeurs doivent toujours écrire leurs requêtes, sauf qu'elles sont traitées par une couche intermédiaire (avec sa syntaxe spécifique et ses lenteurs associées).

   Quels que soient les développements effectués, il faudra bien aller voir en base de données si tout est stocké correctement. Et donc, il faudra bien taper des requêtes SQL. Un développeur Web qui n'en est pas capable aura vite des soucis.

2. Si la volonté de ne manipuler que des objets peut se comprendre dans certains environnements, le “PHP way of life” s'accomode très bien du transfert de données à base de simples listes et tableaux associatifs. C'est la manière la plus souple et rapide d'architecturer ses développements en PHP.

   On peut d'ailleurs remarquer que même les développeurs qui ne veulent manipuler que des “entités” (les objets représentant les données en base) utilisent des tableaux associatifs lorsqu'ils se connectent à des APIs. Pourtant, on pourrait se dire que les données doivent toujours être manipulées de la même manière, peu importe leur source.

3. La vraie couche d'abstraction est constituée par les DAO. Le code métier qui y fait appel n'a pas à être modifié, même en cas de modifications profondes qui imposent de changer les requêtes présentes dans les DAO.

Plutôt que d'utiliser un ORM existant comme Doctrine ou de se baser sur le pattern Active Record, Temma utilise le pattern Data Access Object (DAO en abrégé). Celui-ci est à la fois plus efficace dans son exécution et plus simple à employer.

L'utilisation des DAO est limpide :

• Pour récupérer les données d'un enregistrement dans une table, on appelle une méthode de la DAO. On récupère un tableau associatif, qui propose une clé pour chaque champ dans la table.
• Quand on récupère plusieurs enregistrements d'une table, on obtient une liste de tableaux associatifs. On peut itérer dessus avec toutes les fonctions natives de PHP comme foreach. C'est simple, clair, efficace.
• En évitant de convertir chaque ligne de résultat d'une requête en objet, on évite de consommer inutilement de la mémoire et de faire des traitements supplémentaires.

Les attributs qui ont un underscore au début de leur nom sont créés automatiquement par Temma :

• $this->_session est créé par le framework, sauf si la configuration désative explicitement les sessions.
• $this->_loader est toujours créé par le framework, pour gérer l'injection de dépendance.

Contrairement à cela, les attributs d'accès aux sources de données ont le même nom que ce qui a été défini dans la section dataSources de la configuration (voir la documentation).

Ces noms dépendent entièrement de votre configuration. Par exemple, la connexion à la base de données peut s'appeler autrement que "db" (vous pouvez choisir "database", "sql", "mysqlserver3", ou autre).
Toutefois, notez bien que le plugin de mise en cache s'attend à ce que la connexion au cache s'appelle effectivement "cache" et pas autrement.

Le composant d'injection de dépendances de Temma fonctionne selon un schéma très classique. En soi, il est similaire à d'autres composants comme PHP-DI (voir Understanding Dependency Injection).

Il faut comprendre que Temma ne fait pas d'auto-wiring. Si on prend l'injection de dépendance dans son usage le plus extrémiste, tous les objets se retrouvent à devoir être instanciés par le framework. Oui, tous les objets, même ceux utilisés une seule fois dans un cas très rare.

Le composant de Temma s'utilise plus comme un Service locator, ce qui comporte des avantages (voir In Defense of Service Locator).