Jour 2 - Modéliser les articles avec une entity BlogPost propre

Un blog crédible commence par une donnée propre. Si le modèle est flou, le front et l’admin deviennent vite instables.

Aujourd’hui on crée un BlogPost orienté usage réel: titre, slug, extrait, contenu, statut et date de publication.

Objectif d’apprentissage

Créer une entity claire pour les articles, avec des champs utiles en production et des règles de validation qui protègent la donnée.

Ce que tu vas pratiquer aujourd’hui

• Choisir les bons champs métier dès le début.
• Ajouter des contraintes de validation Symfony.
• Produire une migration Doctrine lisible et vérifiable.
• Préparer un modèle qui peut évoluer sans casse.

1. Générer l’entity avec les champs essentiels

Commence simple, mais complet. Un article a besoin d’un title, d’un slug, d’un excerpt, d’un content et d’un statut.

Garde les types stricts et des longueurs réalistes.

#[ORM\Entity]
class BlogPost
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

    #[ORM\Column(length: 180)]
    #[Assert\NotBlank]
    private string $title = '';

    #[ORM\Column(length: 180, unique: true)]
    #[Assert\NotBlank]
    private string $slug = '';

    #[ORM\Column(type: 'text')]
    private string $content = '';
}

2. Ajouter les règles de validation utiles

La validation évite d’enregistrer des contenus cassés depuis l’admin ou les formulaires publics.

C’est un garde-fou simple qui améliore la qualité fonctionnelle immédiatement.

#[Assert\Length(max: 180)]
private string $title = '';

#[Assert\Regex(
    pattern: '/^[a-z0-9]+(?:-[a-z0-9]+)*$/',
    message: 'Le slug doit être en minuscules avec des tirets.'
)]
private string $slug = '';

#[Assert\Length(min: 120, minMessage: 'Le contenu doit être assez détaillé.')]
private string $content = '';

3. Créer et exécuter la migration

Lis toujours le SQL généré. Une migration ne doit pas être appliquée "les yeux fermés".

Ce contrôle simple évite des erreurs coûteuses en staging ou prod.

php bin/console make:migration
php bin/console doctrine:migrations:migrate
php bin/console doctrine:schema:validate

Checklist de fin de session

• Entity BlogPost créée avec des champs utiles.
• Contraintes de validation ajoutées.
• Migration exécutée sans erreur.
• Schéma Doctrine validé.

Erreurs fréquentes à éviter

• Sauter la vérification finale parce que “ça marche chez moi”.
• Mélanger trop de logique dans le controller au lieu de garder un flux clair.
• Oublier la cohérence entre la donnée, le template Twig et le comportement en production.

Pourquoi cette étape compte en conditions réelles

Dans un vrai projet client, chaque étape technique doit rester compréhensible par l’équipe, duplicable sur un autre environnement et fiable dans le temps. Ici, l’objectif est de transformer la théorie en un flux de travail concret, avec des décisions simples que tu peux défendre en revue de code.

Si tu appliques sérieusement les points du jour (choisir les bons champs métier dès le début.), tu réduis la dette technique dès le départ et tu facilites la suite: SEO, publication, maintenance et déploiement. C’est exactement la différence entre un blog “démo” et un blog exploitable en production.

Mini plan de révision

• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Choisir les bons champs métier dès le début.
• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Ajouter des contraintes de validation Symfony.
• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Produire une migration Doctrine lisible et vérifiable.

Exercice rapide

Ajoute un champ booléen featured et teste une migration de modification propre.

Et demain ?

Demain, on prépare le Repository et les requêtes pour afficher les articles publiés proprement.