Symfony 7 : Comprendre les services

[@veroz9851]

Bonjour! Quand tu as créé la classe Demo.php, tu as cliqué sur src pour faire apparaitre le menu contextuel ? c'est une extension qui fait ça? si oui laquelle? ça a l'air top

[@PresteusSparkling]

10:40 On est d'accord que c'est une *Bad Practice* que d'utiliser l'appel du *container* ? 11:25 Merci ! On est d'accord 😘

[@jaysonmansuy-e1i]

Symfony 7 va faire des ravages ! :)

[@PresteusSparkling]

1:55 Petite coquille -> Le filtre sur le *debug:autowiring* remonte toutes les services contenant le terme « *form* » et non débute par 😉

[@jaysonmansuy-e1i]

La suite ! :)

[@jadbenabderazzak4241]

Merci grafikart

[@z4k_39]

Merci pour ces points assez clairs ! :) Est-ce que l'autowiring c'est "ni plus ni moins" qu'un Dependency Injection Container ? J'ai du mal à voir comment ça fonctionne derrière et je trouve ça un peu "magique" en PHP. J'ai jamais pratiqué le DIC, j'en connais que le principe théorique : Créer une classe container pour pouvoir instancier les objets dont la classe aura besoin

[@Vin974]

C'est pas vraiment des singleton (y'en a peut être quelques un) mais la plupart ce sont des classes instanciable et Symfony n'en garde qu'une instance (mais aussi possible de changer ce comportement dans de rare cas)

[@AkioJunichiro]

Alors je n'ai ni regardé la video ni quelconques connaissances sur ce Framework. Mais si Symfony garde une instance et que cette instance est accessible partout cela me semble etre une implementation de singleton.

[@PresteusSparkling]

C'est le Singleton Pattern qui est exploité par le concept IOC. Une classe de service ne possède pas d'état, elle se doit d'être unique. Une entité, par exemple, ne peut pas être un Singleton, son état dons son cycle de vie évolue 😉 Toutefois, l'autowiring est un mécanisme d'instanciation pour lequel une entité peut être exploitée.

[@AnisD756]

Question sémantique : Est-ce que autowiring et injection de dépendances sont 2 'notions' interchangeables ? Est-ce qu'on peux dire que l'autowiring de Symfony c'est juste de l'injection de dépendance ?

[@R.e.n.e]

Je pense que oui vu les commentaire à côté de autowire à 05:17

[@R.e.n.e]

Je pense que autowiring c'est une injection de dépendance automatique

[@PresteusSparkling]

Pour la couche Service, tu parles de conteneurs, il serait appréciable de nommer le concept dès le départ et l'expliquer par la suite. Le terme conteneurs n'est pas assez explicite ; « On parle de Docker ici ? » ; voilà le type de questions qui pourraient émerger. Ici, on parle d'inversion de contrôle (IoC), ce qui permet de mettre en exergue l'approche SOLID *S* Single responsibility principle (responsabilité unique) *O* Open/closed principle (ouvert/fermé) *L* Liskov substitution principle (substitution de Liskov) *I* Interface segregation principle (ségrégation des interfaces) *D* Dependency inversion principle (inversion des dépendances) C'est pas le sujet certes, mais c'est important de transmettre les véritables bumpers qui permettent d'approfondir par la suite 😉

[@grafikart]

Je compte faire une formation dédiée au design pattern pour détailler tout ça. Formation que je placerais avant celle sur symfony.

[@TheKing-vm8kl]

Je n'ai rien compris ici. Si je me base sur mes anciens acquis, les Services en Symfony sont des fonctions statiques qu'on crée. Il y a un exemple sur le site de Symfony.

[@Vin974]

Les services ça reste juste des classes/interfaces PHP et de la conf. Ce qu'il faut retenir c'est d'utiliser les interfaces en injection de dépendance en grande majorité pour Symfony, 95% des injections peuvent être automatique sans conf.

[@vulcanjibe]

Ouch, ça fait longtemps que j avais pas regardé ou en était PHP. Ça a vraiment pris une sacrée claque par rapport a la concurrence 😮

[@MrTiBeN11]

Pourrais tu élaborer un peu ? sur la "concurrence" entre autres

[@vulcanjibe]

@MrTiBeN11 oui bien sûr. Déjà c est hyper verbeux, toute cette terminologie et ces concepts pour faire une simple API CRUD, ça me rappelle les sombres heures de java Spring Boot (autowire et tout ce délire😂). C'est sur que comparer a un framework node comme NestJs on voit que c est resté sur des concepts d un autre temps... Ensuite, qui s amuse (pour ne pas dire s emmerde 😂😂😂) a faire des API CRUD en 2024??? Honnêtement ça ne sert a rien n importe quel BAAS open source te fait ça gratuitement. Pourquoi perdre son temps à coder et recoder sans cesse des trucs évidents. J ai même pas l impression qu il y a un CLI pour générer les squelettes.... Enfin, la superbe interface de démo, ça fait vraiment look bootstrap année 2010, ça fait vraiment désuet (même si c est pas PHP le fautif 😂). Plus inquiétant, il n aborde pas le SEUL sujet important en 2024, la partie sécurisation qui est le sujet sur lequel on doit se concentrer, le reste c est du blabla donc autant ne pas perdre un minute à coder une API CRUD.... Au final, il a fait je ne sais pas combien de lignes de codes (Des centaines voir des milliers) pour coder un CRUD qui se code en quelques dizaines de lignes avec une stack comme Angular+Firebase ou Next/React/Firebase.... C'est là que je dis que ça à vraiement pris une sacrée claque.

[@MrTiBeN11]

​@@vulcanjibe "les sombres heures de java Spring Boot (autowire et tout ce délire😂)' haha j'ai connu ca aussi. Maintenant, je nuancerai vraiment ton propos car il ne parle pas d'API crud mais d'application web, ce n'est pas tout à fait la même chose.. Ca ne reste qu'un tuto, il ne pas se lancer dans la création d'un SCADA web pour monitorer une centrale nucléaire non plus.. Egalement son tuto est éclaté dans un ensemble de vidéos il n'aborde ici que la partie service/Injection de dépendances. Il abordera je suppose la partie sécurité dans une autre. Et non la sécurité n'est pas l'unique sujet à évoquer dans le design d'une solution web/cloud! Il est certe critique mais reste juste un sujet parmi un ensemble de considérations bien plus vaste, pour tout projet ayant une problématique un peu plus complexe qu'un blog ou un brochureware. J'ajouterai également que tu semble ne considérer que les projets from scratch. C'est sans compter le parc d'appli immense reposant aujourd'hui sur Symfony et autres technos qui ne sont plus dans la hype du moment mais qui doivent être maintenu car le bizness de leur propriétaire repose dessus. Et pour ca heuresement que Symfony, Spring et autres sont encore mis à jour. On ne migre pas une appli complexe et stable qui compte des milliers et des milliers de ligne de code tous les 4 matin vers les nouvelles techno cloud et architectures à la mode. En un mot tu passe complètement à côté du concept de "pérénité". Combien d'initiative de migrations technologiques j'ai vu se casser la gueule, du type ouai votre bouzin monolith sur spring c'est l'enfer va falloir faire du microservice maintenant avec des API Rest en node, du react avec le super templating CSS à la mode etc.. Résultat le projet à pris 4 ans, est devenu 3 fois plus complexe et ingérable, a coûté des milliers d'euros, et de plus toutes leurs nouvelles briques logiciels sont à présent désuettes parce la moitié des technos hypes JS retenues n'ont pas survécu... Il n'y a pas de solution miracle en informatique sinon nous serions au courant et au chomage. Dans ce cas je pourrai dire, pour s'emmerder à faire de l'angular et du firebase, il y a chatGPT maintenant.. Come on boy.