Object Mapper Laravel Package

Technical Evaluation

Architecture Fit

• Symfony Ecosystem: Near-perfect fit for Symfony 8.4+ applications leveraging attribute-driven architecture (e.g., API Platform, Symfony UX). Aligns with Symfony’s declarative patterns (e.g., [Map] attributes) and layered architecture (e.g., DTO ↔ Entity transformations).
• Laravel Incompatibility: Poor fit due to:
  • Symfony dependency: Requires Symfony components (e.g., Attribute, PropertyAccess), introducing vendor lock-in.
  • PHP 8.4+ requirement: Laravel projects often use PHP 8.1–8.3, making adoption blocked without upgrades.
  • Lack of Laravel integrations: No service provider, facade, or Laravel-specific documentation.
• Alternative Patterns: Laravel prefers Spatie DTOs (lightweight), Fractal (API serialization), or custom mappers (flexibility).

Integration Feasibility

• Symfony:
  • Seamless: Integrates with Symfony’s DI container, attribute system, and messenger component (e.g., mapping commands to domain objects).
  • Example Use Cases:
    • API Layer: Transform UserEntity → UserDTO with nested AddressDTO using [Map] attributes.
    • Domain Layer: Map CreateUserCommand → UserAggregate with conditional logic.
  • Tooling: Works with Symfony CLI, PHPStan, and Doctrine annotations (if using legacy setups).
• Laravel:
  • Non-Trivial: Requires manual shimming (e.g., polyfilling Symfony’s Attribute class) or composer scripts to bypass dependencies.
  • Risks:
    • Dependency conflicts: Symfony’s PropertyAccess may clash with Laravel’s illuminate/support.
    • Performance overhead: Adding Symfony’s reflection-heavy mapper to a Laravel app could bloat autoloading.
    • Maintenance burden: Future Symfony updates may break Laravel compatibility.

Technical Risk

Key Questions for TPM

1. Symfony Projects:

   • Are we committed to Symfony 8.4+? If not, this package is premature.
   • Do we need advanced mapping features (e.g., nested objects, conditional logic)? If yes, this may justify adoption.
   • How will this reduce technical debt vs. custom mappers or Serializer?
   • Will this integrate with our existing DTO/Command patterns (e.g., Messenger, API Platform)?

2. Laravel Projects:

   • Why not use Spatie DTOs or Fractal? This package offers no unique value for Laravel.
   • Are we willing to upgrade PHP 8.1→8.4+ just for this? If not, abandon immediately.
   • What’s the cost of maintaining a Symfony dependency in a Laravel codebase?
   • Does this align with our long-term architecture (e.g., microservices, shared libraries)?

3. Cross-Cutting:

   • How will this impact CI/CD (e.g., Symfony’s Attribute requires PHP 8.4+ tooling)?
   • What’s the ramp-up cost for teams unfamiliar with Symfony’s attribute system?
   • Are there alternative lightweight mappers (e.g., league/glide, matthecatlab/uml) that avoid Symfony dependencies?

Integration Approach

Stack Fit

Migration Path

Symfony Adoption (Recommended)

1. Prerequisites:
   • Upgrade to Symfony 8.4+ and PHP 8.4+.
   • Ensure Composer and PHPStan support Symfony’s Attribute system.
2. Implementation Steps:
   • Step 1: Add to composer.json:

     "require": {
         "symfony/object-mapper": "^8.0"
     }
     

   • Step 2: Configure in services.yaml (if not auto-discovered):

     Symfony\Component\ObjectMapper\ObjectMapper:
         arguments:
             - ['@property_access']
     

   • Step 3: Define mappings using attributes (e.g., #[Map]):

     #[Map(target: UserDTO::class)]
     class UserEntity { ... }
     

   • Step 4: Inject ObjectMapper into services:

     public function __construct(private ObjectMapper $mapper) {}
     

   • Step 5: Replace manual DTO hydrators with:

     $dto = $mapper->map($entity);
     

3. Testing:
   • Use Symfony’s ObjectMapperTestCase or custom assertions.
   • Validate nested mappings, conditional logic, and collection transforms.

Laravel "Integration" (Not Recommended)

1. Workarounds (High Risk):
   • Option A: Polyfill Symfony’s Attribute and PropertyAccess (complex, unsupported).
   • Option B: Use Composer scripts to conditionally load the mapper (hacky, fragile).
   • Option C: Abandon and use Spatie DTOs or Fractal.
2. Example (Avoid):

   # composer.json
   "extra": {
       "laravel": {
           "dont-discover": ["Symfony\\Component\\ObjectMapper\\*"]
       }
   }
   

   // Manual shim (not advised)
   $mapper = new \Symfony\Component\ObjectMapper\ObjectMapper(
       new \Symfony\Component\PropertyAccess\PropertyAccess()
   );
   

3. Risks:
   • Dependency hell: Symfony’s PropertyAccess may conflict with Laravel’s illuminate/support.
   • No updates: This package is Symfony-only; Laravel issues will be ignored.
   • Maintenance nightmare: Future Symfony updates may break Laravel compatibility.

Compatibility