Modernisation de DataMapper Bundle de v1 à v2

Date: 27 décembre 2025
Version: 2.1.0-alpha
Basé sur: kassko/data-mapper v2.32.1-alpha (branche 2.0)

---

Structure du projet

src/
├── DataMapperBundle.php              # Bundle principal avec boot() pour initialisation
├── DependencyInjection/
│   ├── Configuration.php             # Configuration du bundle
│   └── DataMapperExtension.php       # Extension pour l'injection de dépendances
├── DataCollector/
│   └── DataMapperDataCollector.php   # Intégration Symfony Profiler
└── Service/
    ├── ServiceResolverFactory.php    # Factory pour créer ServiceResolver avec container
    └── DataMapperConfigurator.php    # Configuration post-construction du DataMapper

config/
└── services.yaml                     # Définitions des services

templates/
└── Collector/
    └── data_mapper.html.twig         # Template du profiler avec timeline, groupement, stats

tests/
├── Unit/                             # Tests unitaires
└── Integration/                      # Tests d'intégration avec kernel Symfony

---

Fonctionnalités implémentées

1. Initialisation dans boot()

Le contexte DataMapper est initialisé au démarrage du bundle pour que les data objects aient accès au Loader. Cette approche permet de coupler faiblement les data objects avec le loader tout en les conservant sérialisables.

class DataMapperBundle extends Bundle
{
    public function boot(): void
    {
        $this->initDataMapper();
    }

    private function initDataMapper(): void
    {
        $this->container->get('kassko_data_mapper.data_mapper');
    }
}

2. Injection de dépendances

• ServiceResolver : Intégration avec le container Symfony pour résoudre les services
• Cache : Support PSR-16 configurable
• Logger : Support PSR-3 avec canal Monolog configurable

3. Data Lineage Profiler

Panneau dans le Web Profiler Symfony avec:

• Timeline des événements : Vue chronologique des opérations de données
• Groupement par classe : Événements organisés par classe d'objet
• Groupement par type : Événements organisés par type d'opération
• Statistiques :
  • Nombre total d'événements
  • Appels DataSource
  • Hydrations de propriétés
  • Propriétés ignorées (avec raisons)
  • Profondeur maximale d'hydration
  • Durée totale

4. Commandes console intégrées

# Valider une classe spécifique
php bin/console datamapper:validate:class 'App\Entity\User'

# Valider toutes les classes d'un répertoire
php bin/console datamapper:validate src/Entity --namespace='App\Entity'

5. Configuration flexible

# config/packages/kassko_data_mapper.yaml
kassko_data_mapper:
    enable_lineage_collection: false  # Activer la collecte du lineage
    enable_profiler: true              # Activer l'intégration profiler
    
    cache:
        enabled: false
        service: null                  # Service PSR-16 (ex: 'cache.app')
    
    logger:
        enabled: true
        service: 'logger'              # Service PSR-3
        channel: 'data_mapper'         # Canal Monolog
    
    validation:
        paths: []                      # Chemins à scanner
        namespaces: []                 # Namespaces pour résolution

---

Tests

• 36 tests avec 69 assertions
• Tests unitaires pour tous les composants
• Tests d'intégration avec un kernel Symfony réel

./vendor/bin/phpunit

---

Fichiers clés modifiés/créés

Fichier	Description
composer.json	Dépendances mises à jour (Symfony 5.4/6.x/7.x, DataMapper ^2.32)
README.md	Documentation complète avec exemples
CHANGELOG.md	Journal des changements v2.0
phpunit.xml.dist	Configuration PHPUnit
.gitignore	Fichiers à ignorer

---

Dépendances

Require

• PHP >= 8.1
• kassko/data-mapper ^2.32
• symfony/framework-bundle ^5.4|^6.0|^7.0
• symfony/dependency-injection ^5.4|^6.0|^7.0
• symfony/config ^5.4|^6.0|^7.0
• psr/log ^1.0|^2.0|^3.0
• psr/container ^1.1|^2.0

Require-dev

• phpunit/phpunit ^9.5|^10.0|^11.0
• symfony/console, finder, http-kernel, twig-bundle, web-profiler-bundle, yaml

---

Points clés de l'architecture

1. Découplage : Les data objects restent sérialisables sans dépendance directe sur le Loader
2. Initialisation paresseuse : Le contexte est créé au boot du bundle
3. Intégration native Symfony : Utilisation des standards (DI, Configuration, DataCollector)
4. Extensibilité : Configuration flexible via YAML
5. Debugging : Profiler complet pour tracer le flux de données