일반 PHP 속도의 DTO

Table of Contents - The Reflection Tax - What If We Just… Generated the Code? - Why Another DTO Library? - Basic concept - History - Features That Matter - 1. Multiple Configuration Formats - 2. Mutable and Immutable Options - 3. Smart Key Format Conversion - 4. Collections with Type Safety - 5. Deep Nesting and Safe Access - 6. TypeScript Generation - 7. Field Tracking for Partial Updates - 8. OrFail Methods for Non-Null Guarantees - 9. Required Fields - 10. Validation Rules - 11. Enum Support - 12. Value Objects and DateTime - 13. Transform Functions - 14. DTO Inheritance - 15. Array Shapes - 16. JSON Schema Generation - Also: - Real-World Patterns - Performance: The Numbers - When to Use php-collective/dto - Summary - Migration Path: From Arrays to DTOs - Demo Zero Reflection, Zero Regrets Every PHP developer knows the pain. You’re deep in a template, staring at $data['user']['address']['city'] , wondering if that key actually exists or if you’re about to trigger a notice that’ll haunt your logs forever. DTOs solve this. But the cure has often been worse than the disease. This post aims to: - raise awareness about array > ArrayObject > DTO performance loss - provide a high-speed alternative to reflection libraries with the same feature set (or more) The Reflection Tax Modern PHP DTO libraries are clever. Too clever. They use runtime reflection to magically hydrate objects from arrays, infer types from docblocks, and validate on the fly. It’s beautiful—until you profile it. Every. Single. Instantiation. Pays the reflection tax. For a simple API endpoint returning 100 users? That’s 100 reflection calls. For a batch job processing 10,000 records? You’re burning CPU cycles on introspection instead of actual work. And then there’s the IDE problem. Magic means your IDE is guessing. “Find Usages” becomes “Find Some Usages, Maybe.” PHPStan needs plugins. Autocomplete works… sometimes. What If We Just… Generated the Code? Here’s a radical idea: what if we did all that reflection once, at build time, and generated plain PHP classes? Introducing php-collective/dto: The Code-Generation Approach Data Transfer Objects (DTOs) have become essential in modern PHP applications. They provide type safety, IDE autocomplete, and make your code more maintainable. But the PHP ecosystem has long debated how to implement them: runtime reflection or manual boilerplate? php-collective/dto takes a third path: code generation. Define your DTOs once in configuration, generate optimized PHP classes, and enjoy the best of both worlds. Why Another DTO Library? The PHP DTO landscape in 2026 looks like this: - Native PHP 8.2+ readonly classes: Manual implementation - spatie/laravel-data: Laravel-specific, runtime reflection - cuyz/valinor: Framework-agnostic runtime mapper - symfony/serializer: Component-based serialization These are excellent tools, but they share a common limitation: runtime reflection overhead. Every time you create a DTO, the library inspects class metadata, parses types, and builds the object dynamically. What if we did all that work once, at build time? Basic concept The idea is not that radical after all. Similar implementations have existed for more than 15 years, way before modern PHP and the new syntax and features it brought along. I have been using it for a bit more than 11 years now myself. You decide on config as XML, YAML, NEON or PHP. PHP using builders is the most powerful one, as it has full auto-complete/type-hinting: return Schema::create() ->dto(Dto::create('User')->fields( Field::int('id')->required(), Field::string('email')->required(), Field::dto('address', 'Address'), )) ->toArray(); Run the generator: vendor/bin/dto generate Get a real PHP class: class UserDto extends AbstractDto { public function getId(): int { /* ... */ } public function getEmail(): string { /* ... */ } public function getAddress(): ?AddressDto { /* ... */ } public function setEmail(string $email): static { /* ... */ } // ... } No magic. No reflection. Just PHP. What You Get - Perfect IDE Support – Real methods = perfect autocomplete, “Find Usages”, refactoring - Excellent Static Analysis – PHPStan/Psalm work without plugins or special annotations - Reviewable Code – Generated classes appear in pull requests - Zero Runtime Overhead – No reflection, no type parsing per instantiation - Framework Agnostic – Works anywhere PHP runs History The concept was first used almost 2 decades ago in e-commerce systems that had a high amount of modular packages and basically disallowed all manual array usage. All had to be DTOs for maximum extendability and discoverability. The project could add fields per DTO as needed. The XMLs of each module as well as project extensions were all merged together. XML makes this easy, and the generated DTOs are fully compatible with both core and project level. I never needed the “merging” feature, but I did like how quickly you could generate them, and that it could always generate full DTOs with all syntac