ok dans ce cas je comprends par contre vu cette difference de perfs que l'on soit pratiquement obligé a etre sous Linux( car oui franchement je voudrais pas travailler sur un truc qui mouline)Citation:
Envoyé par bilbot
Version imprimable
ok dans ce cas je comprends par contre vu cette difference de perfs que l'on soit pratiquement obligé a etre sous Linux( car oui franchement je voudrais pas travailler sur un truc qui mouline)Citation:
Envoyé par bilbot
Je n'ai pas testé sous Windows et je ne compare pas à SF1 qui était un veau.Citation:
Envoyé par bilbot
Sous Linux avec une machine sous Atom / 4G de ram qui me sert de serveur, une simple page qui ne charge pas la base de données, j'ai un temps moyen de 600 ms à plus d'une seconde avec 6,5Mo de conso de mémoire.
+1Citation:
Envoyé par MaitrePylos
J'espère aussi que le temps investit dedans ne soit pas perdu, à cause de passage en version qui casse tout (le framework perdrait son utilité si il devient trop lourd à maintenir). Ou tout simplement à cause d'une perte de productivité.
Pour l'instant j'en suis à la barrière d'acquisition de SF2, donc la productivité est forcément réduite vue que je passe plus de temps à rechercher et tester qu'à avancer. Vivement que ça s'inverse quand j'aurais un peu plus de pratique :)
Avez-vous remarqué un gain de productivité une fois les reflex/pratiques en place ?
Pour Zend, rien n'empêche de l'utiliser dans SF2. Par contre, ça va consommer pas mal au niveau de la ram avec Zend_Date.
En mode production ou dev ? Si c'est en prod je pense que tu as un soucis de paramétrage (APC/génération du cache...)Citation:
Envoyé par FrontLine
pareil petit précision pour Doctrine, personne n'est obligé de faire de l'ORM, On peut très bien faire ces propres requêtes
Sous Windows, faut bien configurer APC et utiliser ApcUniversalClassLoader, sinon ça sert pas a grand chose ;)
ApcUniversalClassLoader il faut l'indiquer dans autoload.php, à la place de UniversalClassLoader ?
edit: effectivement, c'est expliqué ici : http://symfony.com/doc/2.0/book/performance.html
Oups effectivement, niveau temps en mode production c'est mieux, niveaux mémoire c'est encore trop : Time : 0.191 sec | Mem usage : 4,35 Mo (Mem peak : 5,10 Mo)Citation:
Envoyé par bilbot
Mise à part un template qui fait 3 héritages (d'autres templates) il n'y a rien de spécifique. Le template est simple quelques lignes, un top barre et le contenu.
Sinon avez-vous remarqué un gain de productivité une fois les reflex/pratiques en place ? C'est intéressant de savoir car c'est un des principaux buts recherché au final :)
Je voulais juste partagé un lien d'un tuto qui me parait pas mal.
J'en suis a l'etape 2 et pour l'isntant ca ressemeble furieusement a un jobeet.
En fait, je suis la méthode et je construis les pages de mon propre site web du coup.
http://keiruaprod.fr/symblog-fr/
Benchmark accablant pour symfony2 : https://github.com/seedifferently/th...ework-shootout
Plus ça va et plus je me dis que je perds mon temps avec SF2 ... surtout au niveau de la configuration trop chronophage et certaines choses à la Java mais en PHP (ça n'a pas de sens). Je cherche un autre mais j'ai l'impression qu'il n'y a pas "the framework" qui me convienne.
A part FuelPHP mais il est encore un peu trop jeune.
Ce genre de test sur un Hello World à toujours été ridiculeCitation:
Envoyé par FrontLine
https://github.com/alexandresalome/B...For-Benchmarks
Encore une fois je rappelle qu'il y'a 2 choses dans Symfony : les Composant et le Framework.
Si le framework ne vous convient pas, il y'en a d'autre comme Silex par exemple, et les excellent articles de Fabien pour créer un Framework selon ses besoins : http://fabien.potencier.org/article/...ponents-part-1 :ccool:
Bonjour,
Cela fait quelques jours que je mets en pratique le tutorial symfony 2 que j'ai mis un peu plus haut dans un projet personnel. (6-7 heures de boulot pour l'instant)
J'ai un peu utilisé symfony 1 dans mes expériences professionnelles précédentes.
Alors, premières impressions sur ce frameworks.
Dans l'ensemble il est assez complexe à appréhender et la documentation sur le site de symfony est déplorable. C'était leur plus grand point fort, au travers de jobeet qui quoi qu'on en dise remplaçait 10 000 pages d'API. Je ne pense pas avoir été le seul auquel se boite a dit : fais jobeet les 2 premières semaines, ca ira mieux après. On y apprenait des bonnes pratiques et surtout on abordait tous les points méthodiquement, de façon mémorisable permettant de retrouver facilement une information ou une syntaxe que l'on aurait pu oublier.
Pour quelqu'un comme moi qui ne retient rien et qui me réfère toujours à la doc, c'était pratique.(en particulier les lignes de commandes)
Malgré tout, une fois que l'on a passé 1 heure à chercher le bon tuto sur le net, on peut commencer à découvrir le frameworks.
Si comme je le soulignais il est difficile à appréhender, entre autre par son avalanche de thèmes et de concepts hautement inutiles dans 95% des sites web. (Qui a besoin de la flexibilité des bundles pour faire un site de base... lorsque les tutoriels conseille tout bêtement de recréer un 2nd projet si l'on a une autre application à faire...)
Il n'en demeure pas moi intéressant et j'ai bien aimé le découpage avec app d'un coté et sources de l'autre.
J'ai un peu pesté au début parce que j'avais mis un nom de projet long et un nom de Bundle tout aussi long, avant de m'apercevoir qu'on devait les retaper 15 fois par page. J'aurais limite envie de mettre maintenant :
Application A.
bundle : BBundle.
Ca me ferait gagner un max de temps et limiterai beaucoup les erreurs de frappe.(on perd en lecture, mais comme ce sont 2 informations proprement inutiles , on ne va pas se fâcher pour si peu...)
Pour les entités et leur génération, j'ai apprécié d'avoir le choix de me passer des annotations. je suis peut être moi aussi de la vieille école, mais j'aime mieux séparer les choses qui n'ont rien à voir entre elles. Un schéma objet et un schéma BDD n'ont pas vocation à être ensemble dans un fichier et je pense que rien que l'idée qu'un schéma de BDD puisse être délégué a des commentaires éparpillé de partout montre bien le dédain qu'on montre pour le design de ce schéma.
C'est dommage quand on pense qu'il s'agit du cœur de l'application et de ce qu'il y a de plus critique dans celle ci.
Bon, c'est habituel dans le monde de la programmation, java et hibernate avaient "innové" avec les annotations, il fallait bien que des moutons suivent le troupeau.
Je pense que si je dois demander de l'aide sur un forum, les gens apprécieront de voir mon fichier en yaml plutôt que ma classe avec toutes mes fonctions personnelles qui parasitent l'information.
J'ai donc apprécié le fait de pouvoir utiliser les fichiers YAML qui centralise mon schéma et qui en plus ont le bon gout de mettre à jour TOUTES les entités en une seule ligne de commande et non une par une. (j'ai apprécié de pouvoir faire une commande automatique sur eclipse pour me passer de la console).
Pour le reste, je me fait plaisir. Les découpages du codes sont a peu prés logiques après quelques heures à travailler dessus, on prend vite le truc pour retrouver l'information et les bugs à droite ou à gauche.
Je reste donc sur une bonne impression finale, malgré la première étape qui m'a très sérieusement fait hésité entre symfony 2 et la version 1.4 du frameworks.
Si Sensio labs ne corrige pas cette erreur pour aider les gens lors de leur apprentissage, cela ne m’étonnerai pas que Symfony 1.4 soit forké et qu'une autre société lui donne une seconde vie.
Pour tous ceux qui ne souhaitent pas découper leur application en Bundles comme le préconise la structure de Symfony, découpage qui s'avère parfois fastidieux et peu cohérent pour des projets contenus, il existe une alternative : KnpRadBundle !
Vous pouvez toujours utiliser des bundles tiers dans vendors, mais les sources de votre application retrouvent une structure plus classique.
Un petit aperçu :
http://www.developpez.net/forums/att...1&d=1330963843
L'image de marque de symfony est nulle ,ça fait framework pour ado boutoneux.
Que c'est constructif !!! Merci pour ta participation.Citation:
Envoyé par sybil
Personellement, je me suis servi de trois frameworks : codeigniter, zend and symfony2.
J'aime sf2 parce que pour moi il a la simplicité de codeigniter, mais la puissance de zend. Il est vrai que la prise en main est un peu lente, mais une fois les principes compris, on navigue très facilement dans le projet.
Le découpage d'application préconisé semble difficile au départ (surtout comparé à CI, ou tout tient dans une dizaine de répertoires... ;) ), mais c'est remarquablement logique. Maintenant, je ne cherche même plus, c'est devenu une seconde nature pour moi :) (ça ne fait que 3 semaines que je suis sur sf2 en passant ;))
Et pour FrontLine : si l'empreinte mémoire de SF2 est trop grande à ton gout, ne t'approche surtout jamais de zend... Tu en ferais des syncopes ;)
Je ne peux qu'approuver. Les quelques discussions que j'ai pu avoir avec des développeurs (en particulier web) dénotent pas mal de mépris pour la base de données. N'importe quel schéma bancal fait l'affaire. On récupère les erreurs au niveau du programme.Citation:
Envoyé par pmithrandir
...Ce qui est parfois à l'origine d'une évolutivité de l'application plutôt faible et d'un code alambiqué.
Je vois clairement pas le problème des annotations pour définir le schéma de base de données, en quoi méprise t-on la base de données. C'est un mécanisme utilisé en Java par exemple, dans d'autre langage tels que ruby ça utilise d'autre mécanisme propre au langage mais le resultat est le même. Il faut pas voir les annotations comme ce qui définit ton schéma de base de données, mais plutôt permettre à l'ORM de faire facilement le mapping entre la base de données et un modèle objet, mais rien n'empêche de se passer d'ORMCitation:
Envoyé par fatbob
C'est surtout un choix technique que de formater son schéma en fonction de l'ORM utilisé, et non privilégier une structure de BDD parfaitement bien formée.
Au vu des coûts de développement, ça peut vite se révéler judicieux. J'y étais réticent au début et finalement, vu le temps gagné en développement, j'accepte totalement de formater mon schéma à la mode de Doctrine2.
Pour expliciter mon aversion envers l'utilisations des annotations, je vais essayer de developper un peu mes arguments.
La base de données a une structure à elle, des contraintes basées sur son fonctionnements, et souvent, elle ne ressemble pas au modele objet ideal.
On va par exemple devoir morceler beaucoup plus pour economiser de la place, ou stocker plus inteligement certaines choses. Pour cela, un tour sur le forum conception BDD vous donnera des informations.
Dans 80% des petits projets web, ca ne change rien. Mais dés que l'on arrive a des tables qui contiennent plus d'un millions de données, on court le risque de voir ses performances s'écrouler d'un seul coup sans raison. (en fait, on dépasse les capacités serveurs, et on passe en mémoire disque le plus souvent, donc on a un site qui ne fonctionne plus)
Un exemple donné par sqlpro, l'enregistrement d'un email.
naturelement, en objet, vous créez une string, et vous aurez tendance a utiliser un varchar en BDD.
Sauf que si vous voulez être un peu puriste, et optimiser en très haut niveau, vous pouvez découper votre email en 2 informations :
L'identifiant
le fournisseur.
Exemple :
test014235@hotmail.com
Vous conservez l'identifiant, mais le hotmail.com va être stocké dans une table a part, et vous ne conserverez que l'identfiant qui permet d'y arriver. Sur 10 millions d'utilisateur avec 2 ou 3 emails par personnes, la différence sera tout a fait notable.
Si un jour vous devez envoyer un email spécifique a tous les utilisateurs d'hotmail(par exemple pour signaler unproblème juste avce eux) vous le ferez en outre de facon plus simple.
Bref, c'est un peu extrème, mais c'est le genre de contrainte que l'on peut avoir en BDD.
Le problème des annotations, c'est qu'elles incitent fortement l'utilisateur a appliquer un shéma objet en BDD. Et ca ne sera pas obligatoirement sencé. A coté de cela, un shéma en yml, se détache de cette reflexion, et donc permet de génerer ses objets en fonction de la BDD, et non le contraire.
On aime ou on aime pas, mais en général, les développeurs actuels ont des notions catastrophiques en BDD, et ne s'en préocupent pas. On note souvent un mépris pour la BDD, qui fait bien plaisir aux consultants dans ce domaine qui se font des corones en or massif. En effet, le jour ou l'appli plante, on répare... le jour ou la BDD est corrompue, on a perdu des données clients... et on est dans la merde.
Les annotations sont donc pour moi, une fausse bonne idée. Elle incite a appliquer des principes objet a une bdd qui en utilise d'autre, et ces annotations ont déjà fait pas mal de dégat en java en éloignant les dev de la conception de BDD. Reprendre une idée comme celle la allors que symfony 1 était centrée sur les données... me parait aller dans la mauvaise direction.
D'un point de vu pratique, sur un forum, je préfère netement qu'on me colle un shéma YML de 30 lignes, plutot qu'une floppée de classes... Je comprendrais mieux la structure et je n'aurai pas de code parasite pour ralentir ma lecture.
Bonjour, que pensez vous au niveau performance,
J'ai installer un symfony2 avec un hebergement mutualisé pro chez OVH et ça rame à mort, avec Zend ce ne ramais pas autant , mais bon je compare zend1 face a symfony2.
Il y a t' il des personnes qui ont constaté que ça fait beaucoup ramé après l'appelle de la même page, la première fois étant normal.
En mode prod ça devrai bien rouler, après ça dépend de la taille de ton site, et comment tu gères l'autoloading, si t'as bien Intl d'installé si t'as APC
Je viens du monde de Django et je vais donc me baser sur cette connaissance pour donner quelques impressions après 1 mois d'utilisation de SF2. Par ailleurs je connais bien le php (j'en ai fait quelques années avant de passer sur Django).
En premier j'ai trouvé que la logique de base était très bien pensée et réalisée. Il y a une grande synergie entre contrôleurs, routeurs, templates, services. Je tiens à préciser que je n'ai pas encore utilisé d'ORM.
Je trouve la structure des répertoires (je parle de celle par défaut) assez confuse. J'étais habitué à avoir un répertoire par application (bundles pour SF2) avec une application commune et de quoi stocker des fichiers statiques par application ou pour le site complet. Je trouve qu'il y a beaucoup trop de fichiers. Je n'ai pas encore trouvé de moyen simple de versionner mes applis. J'avais l'habitude de prendre tout le répertoire racine avec juste quelques gitignore. La j'ai déjà 100Mo de fichiers sur mon petit proj d'un mois.
L'arrivée de Sonata est une bonne nouvelle pour répondre au manque d'interface d'admin mais j'ai l'impression qu'il est encore assez touchy de créer des entités à administrer (j'ai pas encore trop expérimenté). Sous Django il n'y avait vraiment pas grand chose à faire pour activer l'admin sur tel ou tel modèle. Python étant le seul langage utilisé dans le framework, la description des modèles y est lisible.
Les outils de debug paraissent relativement sexy au premier abord (la barre du bas et les beaux écrans d'erreur), je ne sais pas encore comment vraiment en tirer partie.
J'ai trouvé la communauté encore très faible (du moins sur stackoverflow et google.groups). Par rapport à Django je l'estime à 10 ou 20x inférieure (sur stackoverflow: 35k questions avec le tag django contre 4k pour symfony), pas étonnant vu l'age de SF2.
J'aime beaucoup la manière dont on installe/update les vendor bundles avec git. Le fait d'avoir un fichier qui décrit les bundles installés est une très bonne idée. D'ailleurs quand on fait régulièrement des `bin/vendors update` on se rend compte que les outils évoluent beaucoup.
La gestion de la sécurité me parait plus flexible que sur Django. Rien que le fait que les rôles soient hiérarchisables apporte un gros avantage. Je trouve juste dommage qu'on ne puisse pas gérer une simple liste de droits sans forcément qu'ils soient liés à des entités (ACL), enfin j'ai peut-être pas tout vu encore.
Les services me paraissent très intéressants même si je les ai pas encore beaucoup utilisés.
En conclusion je suis assez confiant dans le futur de SF2 (même si je suis personnellement tombé amoureux de Python, ce qui ne m'aide pas assez à apprécier ce qui se base sur php). Je suis persuadé que SF2 sera très largement utilisé dans 2-3 ans.
Bonjour,
Je débarque tout juste dans le monde du développement et je suis aujourd'hui en stage dans une boite qui utilise Symfony, et entreprend de passer à Symfony2.
Mes buts en général sont de retrouver des choses qui existaient sur Symfony premier du nom et de les installer sur le tout nouveau Symfony2. Et là, ça pêche. Des choses qui apparemment étaient évidentes me semblent maintenant difficile à trouver. Par exemple, le plugin SFGuarUser, les FormFilter ou encore la pagination.
J'ai donc la sensation que Symfony2 est en fait un apparat qui cache un contenu vide. D'autant plus par exemple que quand on installe un bundle (via composer), il faut se taper seul à la main l'écriture dans le AppKernel.php de Symfony2 pour bien lui signaler qu'on a un nouveau bundle; qu'il faut parier sur la continuité du développement de bundles externes quasiment pour tout module qui pourrait pourtant être soit intégré directement à Symfony2, soit être recommandés par la documentation officielle, et que dès qu'on veut faire quelque chose de pointu, on ne trouve rien :/
Bon, c'est vrai que ça donne une idée très négative, mais ça me rend perplexe de ne pas trouver d'écho à mes problèmes sur ce framework. Peut-être est-ce dû à la jeunesse de cet outil, qui n'a pas encore déployé toutes ses capacités.
Y a-t-il d'autres personnes qui soient du même avis que moi ?
moi j'utilise FosUserBundle, simple et pratique à utiliser.
il existe des bundles de pagination
peut être tu ne fais pas de bonne recherche
Le problème n'est pas forcément qu'ils n'existent pas, mais plutôt, lequel choisir quand on a le choix, ou bien dans quelle mesure sont-ils utilisables ? Est-ce qu'ils font le café ? Et le chocolat ? A partir de quel moment est-ce que le bundle montrera ses limites, et faudra-t-il tout recommencer avec un nouveau ?
les bundles font pratiquement toutes les choses principales qu'on peut s'attendre d'un bundle par exemple pour FosUserBundle il fait très bien: login, enregistrement, mot de passe oublié, envois mail activation... mais pas encore le café :mouarf:
ensuite si tu as besoin de fonctionnalités spécifiques, tu peux poser des questions sur les forums: est ce que tel bundle permet de faire tel chose ?
le plus connu est logiquement le plus téléchargé(sur github on vois le nombre de téléchargement) tu peux toujours demander sur les forums ou rechercher avec google: c'est quoi la différence entre sonataBundle et FosUserBundle.
rien ne t’empêche aussi de surcharger un bundle pour modifier/ajouter des choses si tu te sent capable.
Ouaip, je vois, comme par exemple le topic quelque peu plus bas, de quelqu'un cherchant un calendrier ? ^^
la pérennité se pose sur toute chose en informatique. qui me dit que demain jQuery sera encore utilisé ? ou symfony 2? ou django? ou ruby? ou windows 8 ?
un bundle "calendrier" est un cas particulier, utilisé par très peu de personne donc le retour est quasi nul. c'est pareil pour d'autres plateformes : zend ....
il faut peut être trouver le bon compromis: utiliser les bundles les plus connus et utilisé(fosUser, knpPagination...) et se faire sois même ses bundles persos.
Symfony2 n'est pas Symfony 2 (avec un espace). Ce n'est pas la deuxième version de Symfony, avec la même base mais davantage de fonctionnalités. C'est un framework complètement différent, avec des objectifs différents, qui se positionne sur une couche inférieure par rapport à Symfony, composé de briques interchangeables avec une surcouche légère. Cet article l'explique très bien: What is Symfony2? La réponse: un framework HTTP, un framework Request/Response. C'est pour ça qu'il n'y a pas d'admin générator, d'ORM par défaut, de bundles officiel de gestion d'utilisateur... Si tu cherches le successeur de Symfony, ce n'est pas Symfony2 (peut-être est-ce Laravel ?).
Pour les bundles, regarde le nombre de téléchargement et (important) le nombre et l'identité des contributeurs. Quand on a le choix, c'est quand même mieux que d'avoir un bundle officiel qui impose ses choix à tout le monde, non?
Oui, c'est vrai.Citation:
Envoyé par Tsilefy
Bonne question, pour ma part, j'ai l'impression que c'est assez difficile de trouver ce que tout le monde plébiscite. Peut-être parce que je ne connais pas assez le milieu et les bons sites, ou les personnes qui sont des références dans ce domaine. Sans parler d'avoir quelque chose d'imposé, je pensais plus à une note sur la doc officielle de ce qui est le top du top moumoute du moment quoi (exemple avec composer, qui est noté partout dans la doc officielle, mais pas imposé pour autant).Citation:
Envoyé par Tsilefy
Après, l'avantage d'avoir des choses imposées, c'est que d'une part on est à peu près sûr de la robustesse du truc, mais aussi de sa capacité à s’emboîter avec le reste de l'application. Par exemple Doctrine, on est sûr que ça tourne.
Et un des inconvénients des choses qui ne sont pas obligatoires, c'est que ça peut le devenir, rendant des tutoriels et cours complets obsolètes car ils utilisaient un autre bundle.
Je pensais plus à proposer un projet Symfony2 "pour bien démarrer", avec des bundles bateaux installés de base dans les vendors (par exemple le FOSUserBundle, vu qu'il fait l'unanimité) et proposé sur le site officiel, pour qu'après chacun se fasse son idée et ne reprenne que la carcasse Symfony2 pour y greffer ce qu'il souhaite.
Mais c'est sûr que ça offre la liberté de fabriquer son truc comme on le souhaite, de n'avoir rien d'imposé !
Tu cherches peut-être Symfony CMF, qui répond partiellement à cette problématique. Sinon, les bundles de Sonata Project sont excellents.
Sonata est souvent cité, merci pour le lien !
Personnellement pour choisir un bundle je vais sur : knpbundles.com . je fais une recherche par mot clef et je prends le bundle le mieux noté....
Après une utilisation d'un an en entreprise de symfony2, je trouve que son principal défaut c'est les mauvaises pratiques qu'il propose aux débutants "pour gagner du temps". Mais je pense que c'est pour récupérer ses utilisateur de symfony1 qui est rapide/facile a utiliser mais pas très propre.
L'avantage c'est plus je code sous symfony2, mieux j'arrive a architecturer mon travail. Et puis les injections et services sont tip top.
justement ça serai intéressant de pouvoir les trouver quelques parts ces bonnes pratiques. moi ça m’intéresse en tout cas ....
de plus, la plupart du temps chacun à sa recette de "bonne pratique" au final c'est la confusion. Il faut un gros travail de clarté dans ce domaine de la part des élites de symfony
Je songe a faire un article, mais je suis en train de challenger mes convictions.
Je suis encore en mode expérimentation sur pas mal de points techniques.
Par exemple, je commence un projet de test avec aucun formulaire lié a des entités doctrine, mais seulement lié a des entités représentant le formulaire. Ducoup les règles de validation du formulaire ne sont pas mélangés avec la description d'un objet en base de données (vu que c'est pas la même responsabilité et qu'un objet peut être modifié par plusieurs formulaires avec potentiellement des règles de validation différentes.
J'essaye aussi un contrôleur qui n'a pas accès/connaissance au service doctrine.
Perso j'ai encore une grosse recherche à faire au niveau des tests unitaires automatisés utilisant des mocks pour m'assurer que tout ca tienne la route niveau évolutivité maintenabilité.
Après je me considère pas comme une élite
Les premières étapes qui m'ont fait progressé sur mes projets c'est d'utiliser des services pour le code métier (je sais que t'aime pas trop ca dukoid :p)
En gros, le controlleur faisait la sécurité/redirection/hydration de formulaire etc.. Puis, il demande au service de faire une sauvegarde, d'avoir une liste etc... le service fait les requetes et renvoit le tout. C'était pas propre car pas mal de transgression de couches, mais c'est pas mal pour commencer a s'habituer a structurer son code, et sa demande très peu d'effort
déjà, tu peux créer des articles sur les bonnes pratiques concernant les bases de Symfony comme je ne sais pas si tu en vois dans le routing, les controllers, les vues, les assets.
après pour des choses plus pointues comme les entités et formulaires tu verra plus tard.
je trouve vraiment que c'est ce qui manque à Symfony, les bonnes pratiques de bases.
concernant les services je suis un peu réfractaire à les utiliser à toutes les sauces parceque après je trouve que c'est le bordel avec tous ces services à gérer mais il n'y a que les cons qui ne changent pas d'avis :) et puis rien n’empêche d'appliquer les services pour des taches les plus courantes ... mais pour cela il faut l'expertise d'une personne qui maîtrise bien le sujet qui explique bien le pourquoi du comment.
Hello,
J'ai travaillé sous symfony premier du nom pendant deux ans, et j'ai maintenant deux ans de pratique sur le deuxième.
Avec le recul je me rends compte sur pas mal de points que ces deux versions, c'est le jour et la nuit.
symfony 1.x était pour moi beaucoup moins permissif et par conséquent, plus adapté à l'utilisation pour les débutants. Ça avait pour conséquence de laisser moins de place à certaines fautes de conception pour un développeur junior. Pour avoir basculé d'une utilisation de ZF1 à SF1, j'ai trouvé que symfony était plus simple à prendre en main. En revanche, c'était au prix de beaucoup de "magie" interne qui compliquait parfois le debug.
Symfony2 laisse un plus libre choix au développeur et donc s'adresse à mon avis à un public déjà un peu plus averti, au risque de voir apparaitre des raccourcis un peu douteux. Mais paradoxalement, je trouve qu'il permet également de s'intéresser facilement à ces fameuses "bonnes pratiques" en s'appuyant directement sur le code du framework, plus accessible que celui du premier. Le concept le plus important à mon sens étant l'injection de dépendances qui permet de facilement se rendre compte du couplage entre les différentes classes que l'on crée, et donc de la souplesse et la maintenabilité du code.
@gototog : je travaille maintenant depuis 6 mois sur un projet ou les contrôleurs ne manipulent que des services perso. Pas de doctrine dans les contrôleurs, pas de validation de formulaire dans les contrôleurs. De manière à les alléger le plus possible. Le contrôleur reçoit une requête et renvoie une réponse, et entre les deux : des appels à des méthodes de service, des redirections, et des exceptions, pas plus.
L'avantage de manipuler beaucoup de services est justement de se rendre compte rapidement, ou est-ce qu'on a besoin de factoriser, repenser, réorganiser l'architecture. Je trie mes services de cette manière :
- Converter (permet d'instancier un objet avec toutes les jointures que l'on veut lorsqu'on passe par exemple son id dans une route)
- EventSubscriber (traitement des évènements postSave, preDelete, postCustomMethod etc.)
- FormHandler (traitement des formulaires)
- Manager (code métier, persistance des objets etc.)
- plus quelques uns que j'ai du oublier en route...
Niveau bonnes pratiques, je pense que l'idéal encore une fois est de s'intéresser à tout ce que le framework propose, essayer de l'utiliser et voir combien de : lignes de codes|requêtes|mémoire|temps d'exécution (rayez les mentions inutiles) ça te fait gagner. Une utilisation basique du framework sur des projets tutos bateaux comme on en voit fleurir partout sur le net se résume à :
- installer ton environnement de dev
- créer ton modèle
- créer tes contrôleurs et tes routes
- créer des services
- créer deux formulaires et demi pour la forme
Avec ça difficile de trouver des cas d'optimisation et le besoin de bonnes pratiques.
Personnellement je travaille beaucoup avec les Event et EventSubscriber. Je trouve que c'est un concept qui est assez peu abordé et pourtant qui est très utile dans de nombreux cas et limite les oublis et/ou effets de bord.
Les autres bonnes pratiques, ce sont celles de la POO tout simplement. Je ne compte plus les développeurs qui font de l'objet (que ce soit du PHP, Java ou quoique ce soit d'autre), parfois travaillent avec un framework, mais qui n'ont pas assimilé ne serait-ce que deux ou trois DesignPattern. Dans la théorie, ils peuvent t'expliquer comment fonctionne un Decorator ou un Factory, mais n'ont pas le réflexe de se dire : "Tiens, je suis confronté à une problématique qui doit être récurrente en POO. N'y aurait-il pas un DesignPattern qui pourrait résoudre mon problème de la manière la plus propre possible ?".
Pour finir, une chose est sûre, c'est qu'après avoir travaillé avec un framework comme SF2, on a énormément de mal à revenir sur du développement from scratch (qu'on retrouve de moins en moins...et c'est tant mieux).
merci gototog et nico_f pour vos précisions. :P
ça confirme bien qu'il manque vraiment une source fiable et clair pour orienter les débutants vers l'optimisation et les bonnes pratiques une fois les bases acquises.
On est bien d'accord. Quand on débute, comme ma classe par exemple : BTS 2e année, on nous a propulsé sur un projet Symfony2 sans aucun secours de la part du prof qui voulait nous "faire faire de la veille" (de l'autoformation quoi), on constate bien le problème : on n'a pas de bonnes pratiques en tête, un niveau technique très faible, on ne sait même pas ce qu'est le protocole http si on a eu un mauvais prof, mais on doit se démerder avec la patate chaude symfony2.Citation:
Envoyé par dukoid
Par quel bout le prendre ? Qu'est-ce que ça offre par rapport au reste ? Se faire chier à l'utiliser, est-ce vraiment bien ? Et surtout, est-ce que ce qu'on fait, c'est bien dans les standards, les bonnes pratiques ?
C'est difficile quand on suit les cours donnés de pouvoir dire "J'aime symfony2, parce que...", parce que justement, il y a peut-être des frameworks bien mieux ! A mon avis, Symfony est bien plus poussé et orienté développeur et 'côté pratique' que Symfony2. Mais par contre l'organisation de Symfony2 est bien meilleure que pour Symfony pour certaines choses (fichiers repository par exemple).
Il manque sans doute de livres à ce sujet, pour vraiment orienter la programmation.