Discussion :

[Aizen64]

Bonjour à tous,

Pour commencer, je n'utilise pas Symfony directement mais Slim 3 avec certains composants de Symfony (Monolog & Twig notament), l'application est un mix de 3 tiers et MVC :

Schéma : Contrôleur -> Service -> Modèle (SQL) ou WebService REST. Le service fait principalement du mapping quand les données sont numériques en BDD par exemple et que du texte est plus approrié pour l'utilisateur, ou encore du formattage de date si besoin est. Le tout redescend au Control leur qui passe des valeurs au template.

Le problème du service est que parfois, il ne fait rien de particulier à part appeler le modèle.

J'ai 2 contrôleurs/Services dans l'appli : Public et Customer. Public : toutes les pages publiques qui ne requièrent aucune autentification, et Customer pour les users loggés.

Dans le code, j'ai aussi mis des classes Helper qui permettent de faire différentes opérations sur des string/int etc... qui sont statiques.

Mon gros problème est une question d'échelle, le nombre de méthodes est pour l'instant assez limité donc ça me semble maintenable, y a t-il de bonnes pratiques pour garder un code maintenable si l'appli grandit ? J'ai mis du PHPDoc partout avec des uses, used-by pour faire référence au code appelé/appelant et documenté tous les params en entée, documenté mon fichier de config qui dépend de l'env sur lequel l'App tourne mais je trouve ça insuffisant.

Des suggestions ?

[dukoid]

vu que c'est une grosse app celui ci est surement composée de différentes parties (même si ils sont reliés).

avec cet exemple : client, product, command

* niveau controller :
ClientController
ProductController
CommandController

* niveau vue :
/views/common/...
/views/client/...
/views/Product/...
/views/command/...

* les services :
/services/common/...
/services/client/...
/services/product/...
/services/client/...

*les fichiers de config :
services_commun.yml
services_product.yml
...

** et même pourquoi pas, faire un bundle pour chaque partie. chaque bundle à son propre namespace (et ça n’empêche la communication entre bundle)

** autre chose, le nommage des fonctions/methodes/services. un bon nommage tu n'as même pas besoin de mettre des explications :
exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
convertArrayToJson(Array tableau=[])  {                     // on comprend tout de suite ce que ça fait, non ?
   ...
   return $json;        // String
}
 
generateKeybyUser(User user)  {                                                     // clair, aussi ?    à t'on vraiment besoin de mettre des explications ?
   ...
  return $key;         // string
}

[Aizen64]

Merci à toi.

Histoire de comparer mes notes à ton feedback, quelle est ta définition d'un service exactement ? Peux-tu donner des exemples concrets d'opérations effectuées par ces derniers.

Mes autres interrogations :
- ControllerCommun, quelles méthodes implémentées exactement par rapport à un contrôleur spécifique ? Idem pour Service/commun, quelles méthodes/utilité ? Exemples ?

Ce qui me rassure dans ta réponse, c'est que je n'ai pas été totalement à côté de la plaque niveau organisation.

C'est difficile à décrire sans donner de code snippet mais, la grosse erreur que je vois dans mon organisation est que je met par exemple en constructeur de contrôleur un type \Monolog\Logger au lieu de \Psr\Log\Logger interface ce qui m'empêche de changer de manière transparente de Logger si besoin est.

La partie ou je suis moins d'accord avec toi c'est que du PHPDoc permet de documenter toute méthode a peu près correctement. Toujours pas d'attribut Route/méthode HTTP ou encore de définitions de constantes en PHPDoc mais dans l'ensemble ça fait le travail. Là encore, ça a aussi l'avantage qu'un IDE peut fournir des infos sur le type attendu (CTRL + P avec PHPStorm ) sans avoir à ouvrir le fichier contenant la méthode.

[dukoid]

* un service c'est du code métier ou pour factoriser du code.
envoyer un mail, mettre à jour une table d'une base de donnée, récupérer des coordonnées gps, vérifier si un user à certains droits ou pas...

en fait, la bonne pratique est que dans le controller on a que des appels à des services car une action dans un controller ne doit pas dépasser disons 15 lignes.


* concernant la doc, chacun à sa vision.. moi je suis pour un nommage intelligent avec une doc réduite.
ça me gonfle de lire la doc pour chaque fonction(imagine si il y en a une centaine) par contre je trouve pratique de comprendre ce qu'elle fait juste avec un bon nommage...

* controllerCommon est une erreur de ma part. je l'ai supprimé du message précédent.

* /service/common/... c'est disons les services que tu va utiliser un peu partout (dans d'autres services ou dans des controller et que tu ne sais pas ou le classer)
disons un service "générique"
par exemple , connaitre les droits d'un user.
tu peux utiliser un service qui peut être utilisée dans les 3 parties !
ou envoyer un mail générique !


** sinon, si vraiment tu as des parties distinctes c'est mieux d'en faire des bundles distincts

[Aizen64]

OK, pour l'organisation des services c'est l'idée que j'en avais.

Dans certains cas, j'ai mis trop de code dans le contrôleur mais il faudrait que je re travaille un peu dessus et faire du refactoring.

Perso, je trouve l'organisation de Symfony lourde mais je pense comprendre ton argument sur les bundles.

Slim me donne moins de contraintes tout en me permettant de structurer mon code en MVC correctement.

Si javais tu as d'autres bonnes idées, hésite pas.

Ah, j'utilise aussi un Middleware d'authentification qui vérifie que l'utilisateur ait le droit d'accéder à une ressource donnée et un autre qui me permet de gérer un mode maintenance sur toutes les routes de l'appli et renvoyer une réponse 503 avec template Twig.

Ma dernière phrase est pour faire un parallèle avec une app que je dois maintenir (une horreur procédurale avec mélange de PHP, CSS JS inline, appels webservice, SQL) qui est faite avec du PHP brut, ça donne envie de se jeter par la fenêtre. Se mettre dans un framework permet d'avoir une route = une méthode et ne pas se préoccuper du reste. C'est pas évident au départ mais plus structuré.

[dukoid]

déjà de base, on doit avoir un bundle pour le backend et un bundle pour le frontend.
ensuite le bundle back ou front peuvent être divisé en d'autres bundles

* si je prends l'exemple d'un site e commerce, je ferai :
- un bundle backend, of course !
- un bundle "site vitrine" de recherche de produit
- un bundle panier (vue panier, validation, gestion de la livraison)
- un bundle "compte" ou le client peut visualiser ses infos de commandes etc...

* Pour aller plus loin :
Ces bundles peuvent être développés indépendamment, versionné et inclus avec composer dans le .json afin qu'il soit intégré dans le vendor.

* zoom sur le bundle CompteBundle par exemple, on a :
CompteBundle
/Controller/DefaultController.php ........................................ // il n'y a pas besoin de renommer le controller ou services.yml
/resources/config/config.yml ............................................. // puisqu'ils font partis de Comptebundle
/resources/config/services.yml
/resources/views/...

* les listener : à ne pas négliger
ma définition serait la suivante : effectuer une série d'action asynchrone suite à un événement (ou à une autre action)

je prends l'exemple sur un site e commerce.
un client valide une commande, suite à ça vous devez faire une série d'action asynchrone comme :
- envoyer un mail au client : récapitulatif de la commande
- envoyer un mail au vendeur/propriétaire du site web qu'une commande a été passé
- faire un enregistrement dans un log (avec monolog) pour avoir une trace supplémentaire (autre qu'en base de donnée)

ces 4 taches doivent se faire indépendamment les unes par rapports aux autres car bien évidemment il ne faut pas attendre que le mail au vendeur soit effectuer pour ensuite enregistrer un log, il faut que ces 4 taches s’exécutent en parallèle.
pour cela, la validation de la commande est l’événement déclencheur de ces actions.
chacun des observers exécute sa tache.


* et TWIG ?
- déporter la logique dans les vues avec les extensions twig
- utiliser l’héritage de template, les blocks
- utiliser des maccros


* en effet, un framework permet de mieux structurer un projet. Tu sais que la logique est là, que les vues sont là. que les données représentées là... et ce quelques soit le projet Symfony.
de plus , cela permet de gagner du temps de dev. Symfony regroupe plusieurs outils qu'on a pas besoin du coup de développer : routing, twig, gestion des requêtes....
ces outils respectent les PSR, les bonnes pratiques, la sécurité etc.... et d'une fiabilité absolu (notamment sur Symfony ou rare sont les bugues)