Etant symfony2 developer si on apprend Lavarel y - a t-il une raison a aller plus vite dans l'apprentissage ?

Je suis tres habitue avec Symfony2 a d'ailleurs je l'aime beaucoup mais malheureusement mon supperieur n'en connait pas et lui, il es accro a Lavarel alors je me vois dans l'obligation d'apprendre son framework car je dois faire le boulot qu'il va me donner si je perd mon job :roll: ! Alors je veux savoir le fait d'etre deja un developpeur habitue a Symfony2 et surtout parce que Lavarel est l'un des projets qui utilisent certains des composants symfony2 cela va t-elle etre un plus pour moi ? et est - ce que en Lavarel il est possible d'integrer facillement des "standane alone component" de php sous form de bundle en symfony2 ? en symfony2 nous n'avons pas de frontiere est-ce la meme chose chez Lavarel ? Merci d'avance

Bonjour,

si tu maîtrises Symfony2 tu n'auras aucun problème avec Laravel, tu retrouveras pratiquement tous tes petits, c'est surtout l'orm qui change: eloquent. Pour te faire une idée il existe une ancienne documentation de Laravel4 en Francais (pas sur que ce soit ta langue!)

Il est PSR4 compliant et utilise composer: les paquets laravel

Dans laravel tu peux facilement avoir un code spaguéti plus vite qu'avec symfony2

et comme mentioné par papajoker, mon seule souci était l'active record de éloquent

Dans Symfony2 et doctrine2 t'a des entités (des classes php) et à l'aide d'une conf (annotation, yml ou autre) tu dira à doctrine comment les interpreter
y'a aussi le pattern unitoffwork (pense à persist & flush) et la notion de l'entity manager dont tu ne le trouvera pas dans laravel (les models hérite d'une super classe qui contient une methode save (c'est l'old school de propel))

Dans laravel tu aura un dossier migration dont tu met tes scripts de créations de tables et tous le staff sql(avec symfony2 t'a un bundle migration qui detecte les changements dans tes entités et génère un diff => c'est plus éléguant)

l'utilisation du composer pourra faciliter ta tache de migration

pas de notion de bundle

Bonne chance

Tu peux faire du Data Mapper à partir d'Eloquent. Vois ces 3 articles.

Sinon, la courbe d'apprentissage est nettement plus faible pour Laravel (ce qui explique sa grosse popularité).

Citation:

---

Envoyé par Tsilefy

ces 3 articles

---

.
merci pour le lien mais cette solution risque de produire de l'Overengineering

Il y a aussi un package doctrine pour Laravel, mais généralement les "laraveliens" sont bornés et adorent active record (ils se rendront compte des problèmes d'ici deux trois versions, ZF1 utilisait aussi ce pattern et étrangement ZF2 ne l'utilise plus :ptdr:).

Honnêtement, essaye d'utiliser des repositories quand tu utilises Eloquent, et un maximum de view objects façons java. Ensuite, un minimum d'utilisation des façades, essayer de maintenir une programmation par contrat (interfaces) et utiliser l'IoC pour injecter les concretions, et tout devrait bien se passer normalement !

Citation:

---

Envoyé par phpiste

.
merci pour le lien mais cette solution risque de produire de l'Overengineering

---

Pas forcément. C'est moins de travail et plus simple que lorsqu'on écrit son propre Data Mapper à partir de zéro et je ne sais pas si Doctrine s'intègre bien à Laravel. Overengeneering est relatif, il dépend de la portée du projet. C'est sûr que pour un blog ou des landing pages, c'est excessif.

Citation:

---

Envoyé par Théocrite

Il y a aussi un package doctrine pour Laravel, mais généralement les "laraveliens" sont bornés et adorent active record (ils se rendront compte des problèmes d'ici deux trois versions, ZF1 utilisait aussi ce pattern et étrangement ZF2 ne l'utilise plus :ptdr:).

---

Les "Laraveliens" me rappelle les "Railsiens" il y a quelques années :-)

Citation:

---

Envoyé par Théocrite

Ensuite, un minimum d'utilisation des façades, essayer de maintenir une programmation par contrat (interfaces) et utiliser l'IoC pour injecter les concretions, et tout devrait bien se passer normalement !

---

Je dirais même (à MAPOUKA) n'utilise pas les façades, et injecte tes dépendances. Mais comme ton supérieur est accro à Laravel, j'ai peur que tu n'aies pas le choix.

Merci a vous tous !
Je tiens a vous informer que les choses s'etaient tournees en ma faveur: "Je continue avec Symfony". Ce qui me plait tellement car j'ai du mal a croire qu'un autre PHP Framework aurait la taille de Symfony pour l'instant car j'avoue que SensLabs & Fabien Potencier fait reellement peur ... on dirait meme Symfony n'est plus un framework mais un "super-language (4eme generation) additif a PHP" car j'ai du mal a imaginer un projet qui pourait se faire en PHP dont Symfony n'en offre la possibilite de reduire le delait a plus de 80 % (pour ceux qui connaissent ce framework)....desole si vous trouvez que j'abuse mais je crois avoir dis une verite.

Réduire les délais et renforcer la facilité de développement est quand même ce qu'on attends d'un framework, sinon à quoi ça servirait? :P

Donc oui, c'est vrai pour symfony (le pourcentage dépend des points de vue), mais ce n'est pas unique. C'est également vrai pour Laravel, Spring, RoR, Django et beaucoup d'autres.

Alors, ton supérieur est toujours ton supérieur, ou est-il parti?