Hello,

Je suis dev Symfony depuis 10ans. Je fais quelques projets perso pour tester Laravel et pourquoi pas y passer si j'aime mieux. J'ai besoin de faire une app qui a une partie REST api et une partie qui est une boucle infinie. Doctrine gère beaucoup trop mal les connection persistante pour que ca soit utilisable comme tel.

J'ai quelques question sur eloquent.

Sur Symfony la gestion des model est super simple. un petit make:entity, on y indique les champs et ca crée le model avec les annotations qu'il faut et les attributs dans la class. Il suffit ensuite de juste faire un make:migration pour avoir un fichier de migration auto que je peux modifier si besoin.

Dans le model Symfony, je peux suivre facilement les champs présents en base. Par exemple si j'ai un "string $firstName" je sais qu'il y a un champ firstName et j'ai le getter/setter.

Sur Laravel, de ce que je comprend dans la doc il n'y a rien de tout ca.

• Est-ce que je suis obligé de créer chaque migration à la main ?
• Comment vous faites pour suivre les champs disponible dans le model ? Par exemple, j'ai installé le projet et ca a crée une migration create_user_table, j'y vois les champs. Comment je fais pour savoir les champs qui sont disponibles sans devoir ouvrir la table pour vérifier et sans relire chaque migration executé plus tard ? Ca a l'air super fastidieux et peu pratique. Si j'installe un bundle, comment je devines les champs dispo (à part dans la doc) ?

Salut,

Il te faut avoir en tête que Laravel est un fork de Symfony 3. Laravel est beaucoup plus simple que Symfony en terme de fonctionnalité et de facilité de développement (selon moi qui suis passé au contraire de toi de Laravel à Symfony). Donc, oublie la création auto de migration, creation asistée des entités. Les champs dispo dans le model est rempli dans la variable protected $fillable.

C'est pour tout ça que je suis passé à Symfony, perso

Salut,

Mon conseil : ne passe surtout pas de doctrine à eloquent si tu as quelques considérations pour le code "propre".

Ensuite, si je peux me permettre, vu ton post, c'est bien d'utiliser des outils qui te mâchent le travail, mais seulement à partir du moment où tu comprends ce qu'ils font et que tu es capable de le refaire à la main.

Doctrine et eloquent sont des ORMs, c'est-à-dire qu'ils mappent des enregistrements d'un SGBD relationnel type Mysql/Oracle etc... en objets et inversement. L'un des principes fondamental de la programmation objet est l'encapsulation : tes champs sont privés, et sont accessibles uniquement via l'interface publique de l'objet (notamment les getter/setter). Un client (au sens des design patterns) qui utilise l'entité ne doit pas connaître son implémentation, et notamment si les données proviennent d'une BDD, d'un fichier, d'un système en mémoire type REDIS, d'un code en dur, etc...

Dans un monde idéal, tu commences toujours par écrire des classes qui représentent ton domaine, sans prendre en compte la persistance. Déjà mettre des annotations dans une entité c'est une violation du domaine, qui doit être la partie la plus abstraite de ton code et ne faire intervenir aucun corps étranger.

Quand tu as tes entités (classes) qui décrivent avec classe et élégance le domaine métier, tu peux passer aux choses crades et notamment la façon dont tu vas persister les objets (parce que c'est bien rare qu'il ne faille pas les persister quelque part). Si tu as choisi comme système de persistance un SGBD, dans ce cas tu vas utiliser ton ORM, qui va te proposer une ou des façons de mapper ton entité vers un/des enregistrement(s) relationnel(s) (notamment avec les annotations, mais ce n'est pas la seule façon de faire avec doctrine).