DEV Community: Yurii Zub

Simple Data Objects v2: from a fast PHP DTO hydrator to a full Typed Data Boundary

Yurii Zub — Tue, 18 Aug 2026 13:56:58 +0000

Simple Data Objects v2: from a fast PHP DTO hydrator to a full Typed Data Boundary

In a previous article I wrote about an experiment compiling Reflection metadata in PHP to reach extremely fast DTO hydration. That experiment proved one thing: DTOs in PHP can be incredibly fast without sacrificing typing.

But speed in a vacuum is only part of the puzzle. While preparing the Simple Data Objects v2 (SDO) release, I asked a deeper question:

What does a developer actually need from a DTO library in a real, large PHP or Laravel application, beyond a blazing-fast from(array) method?

The answer turned out to be broad: convenient validation, input normalization, support for nested collections, safe error accumulation, flexible serialization, frontend contracts, and framework integration. And, crucially, all of it has to work without losing the legendary performance.

Version 2 grew from a "fast hydrator" into a full, production-ready Typed Data Boundary. Let's look at how it's built, and why performance here isn't just a number in a table but an architectural philosophy.

1. Why plain arrays aren't enough anymore

Arrays in PHP are a great, flexible tool — right up until the moment they start crossing the boundaries between different layers of a system:

HTTP Request ➔ Controller ➔ Domain Service ➔ Queue Job ➔ Database ➔ API Response

At every one of these steps, we're forced to make dozens of micro-assumptions:

$email = trim((string) $payload['email']);
$amount = (int) $payload['amount'];
$date = Carbon::parse($payload['created_at']);

These assumptions gradually get duplicated across controllers, jobs, webhooks and tests. If the array's shape changes on the frontend, the chain breaks in a completely unpredictable place.

A DTO solves this by creating a clear, named contract. All the conversion and validation magic happens once — at the boundary where data enters the system. From then on, your code works with clean, typed objects.

2. Anatomy of a DTO in Simple Data Objects v2

Installation is standard, via Composer:

composer require std-out/simple-data-objects

A basic DTO stays a maximally simple, readable PHP class:

namespace App\Data;

use StdOut\SimpleDataObjects\BaseData;

final class CustomerData extends BaseData
{
    public function __construct(
        public readonly int $id,
        public readonly string $email,
        public readonly string $name,
    ) {}
}

Hydration is direct and safe:

$customer = CustomerData::from([
    'id' => '42', // The string is automatically cast to int
    'email' => 'ada@example.com',    'name' => 'Ada Lovelace',
]);

$customer->id; // int(42)

Your class stays clean, declarative code. The hydration compiler and metadata cache are SDO's under-the-hood work — invisible to the developer, but critical for the CPU.

Important note: while most examples in this article target Laravel (since it's one of the most popular frameworks in the ecosystem), the Simple Data Objects library itself is completely framework-independent! It works great on any other framework (Symfony, Slim, for example) or even on plain (vanilla) PHP.

That said, the Laravel ecosystem gets powerful, opt-in support for a lot of native features! For example, you can automatically inject a DTO directly into a controller method instead of a standard Request object, use a DTO as an Eloquent attribute cast, plug in Livewire integration (WireableData), and use ready-made Artisan commands to warm the metadata cache (sdo:warm) or generate TypeScript. All of these extras are opt-in and never weigh down the core package.

One caveat: the core package still pulls in illuminate/contracts, illuminate/support and illuminate/validation as hard dependencies (without a full Laravel application) — so on Symfony or Slim these packages will show up in your project's composer.json, even if you never touch an Illuminate\* class directly.

3. Data boundaries and flexible usage scenarios

In real life, data arrives with varying levels of trust. SDO v2 offers a distinct approach, splitting the hydration API by scenario:

A. HTTP requests: fast fail-fast validation

When a user submits a form, we need to check the rules quickly and, on failure, return a response:

use StdOut\SimpleDataObjects\Attributes\Rules;
use StdOut\SimpleDataObjects\Attributes\InferRules;

#[InferRules] // Automatically infers baseline rules from PHP types
final class RegisterData extends BaseData
{
    public function __construct(
        public readonly string $name,
        #[Rules(['required', 'email', 'unique:users,email'])]
        public readonly string $email,
    ) {}
}

// Runs Laravel validation and throws ValidationException on failure
$data = RegisterData::fromValidated($request->all());

B. Importing large files (CSV/JSON): error accumulation

If you're importing 100,000 rows from a partner's CSV, failing on the first invalid row is a bad idea. You need to collect a detailed report of every error instead:

foreach (CsvUsers::rows($path) as $line => $row) {
    // Returns a HydrationResult object instead of throwing
    $result = UserImportData::fromValidatedResult($row);

    if (!$result->ok()) {
        $errors[$line + 2] = $result->errors(); // Store the error for the report
        continue;
    }

    ImportUserJob::dispatch($result->value()); // Process the successful DTO
}

C. Lazy typed collections

So that huge imports don't eat up all the available memory, SDO v2 supports lazy hydration through generators:

// Each item is only hydrated at the moment it's iterated over
$lazyCollection = UserImportData::lazyCollection(CsvUsers::rows($path));

foreach ($lazyCollection as $user) {
    // Process one DTO at a time, keeping memory usage flat
}

4. The SDO v2 feature map: everything in one place

SDO v2 uses PHP attributes as the single source of truth for the IDE, static analysis, validation and serialization.

Pipes for input cleanup

Pipes run before the constructor and casts are invoked. They're ideal for mechanical normalization (trimming stray whitespace, lowercasing, and the like):

use StdOut\SimpleDataObjects\Attributes\Pipe;
use StdOut\SimpleDataObjects\Pipes\TrimStringsPipe;
use StdOut\SimpleDataObjects\Pipes\NullifyEmptyStringsPipe;

#[Pipe(TrimStringsPipe::class, NullifyEmptyStringsPipe::class)]
final class ContactData extends BaseData
{
    public function __construct(
        public readonly string $email,
        public readonly ?string $note = null, // An empty string becomes null
    ) {}
}

Built-in and custom casts

SDO ships with a large set of ready-made casts: BooleanCast, IntegerCast, DateTimeImmutableCast, MoneyCast, JsonCast, EncryptedCast (backed by Sodium), and others. You can just as easily write your own by implementing the CastsValue contract.

PATCH API: working with the `Optional` type

The eternal REST API problem: how do you tell the difference between a client sending 'email' => null (they want to clear the field) and them not sending the 'email' key at all (they don't want to touch it)? SDO solves this elegantly:

use StdOut\SimpleDataObjects\Optional;

final class UpdateProfileData extends BaseData
{
    public function __construct(
        public readonly string|Optional $name,
        public readonly ?string|Optional $bio,
    ) {}
}

If a key is missing from the request, the property receives an Optional object instead. During subsequent serialization, such fields are automatically skipped.

Contextual serialization: `#[Hidden(except: [...])]`

A classic problem: one DTO needs to serve both a public API and an admin panel, but not every field should be visible everywhere. Instead of duplicating classes or manually calling except() in every controller:

final class UserData extends BaseData
{
    public function __construct(
        public readonly string $name,
        #[Hidden(except: ['admin'])]
        public readonly string $email,
    ) {}
}

$data->toArray();                  // no email
$data->toArray(context: 'admin');  // includes email

Each context compiles into its own specialized serializer and is cached separately, the same way the default one is — no runtime branching per field.

One contract for both backend and frontend (TypeScript)

No more manually keeping types in sync between PHP and JS/TS. SDO can generate JSON Schemas and TypeScript types directly from your DTOs:

php artisan sdo:typescript app/Data --output=resources/js/types/dto.d.ts

5. Performance: numbers you can verify

SDO's performance is built on the principle of metadata compilation. Instead of parsing classes through the heavy Reflection API on every request at runtime (as most libraries do), SDO analyzes classes once, compiles optimized PHP files for hydration, which get cached by OPcache and run at native-code speed.

Comparative benchmark: SDO vs spatie/laravel-data

For a fair comparison, we built identical fixtures (the same field types, nested objects, and 20-item collections) and ran them in a clean Docker environment (php:8.4-cli-alpine, PHP 8.4.23, Laravel 12.65, Spatie 4.23, OPcache + JIT (tracing) enabled for the CLI SAPI — the base image ships with both off). We measured the pure library overhead (no I/O, DB, or network).

Here are the median throughput results (operations per second, higher is better):

Scenario	Simple Data Objects (SDO)	spatie/laravel-data	Speedup
Flat hydration (simple DTO)	1,162,551 ops/s	83,789 ops/s	13.9×
Nested hydration	3,070,989 ops/s	94,773 ops/s	32.4×
Collection hydration (20 items)	183,041 ops/s	10,570 ops/s	17.3×
Date cast hydration	1,347,300 ops/s	119,791 ops/s	11.2×
Flat serialization (to array)	2,892,779 ops/s	171,100 ops/s	16.9×
Nested serialization	4,674,271 ops/s	164,027 ops/s	28.5×
Collection serialization (20 items)	312,904 ops/s	27,263 ops/s	11.5×
CSV streaming (100k rows)*	71,147 rows/s	38,866 rows/s	1.83×

*Note: the CSV-streaming gap is smaller because a large share of the time is spent parsing the file through native fgetcsv.

CPU load and memory usage

Speed also means smaller server bills. Let's look at pure CPU time (CPU microseconds per operation, lower is better):

Scenario	SDO CPU us/op	laravel-data CPU us/op
Flat hydration	0.84 us	11.86 us
Nested hydration	0.34 us	10.63 us
Collection hydration	5.45 us	96.64 us

And memory usage (retained memory per kept result, lower is better)?

Flat hydration: SDO uses 517 bytes/op vs 533 bytes/op for Spatie.

6. Smart trade-offs

An engineering approach demands honesty. Our benchmark compares against spatie/laravel-data, a very popular and mature library. That package deserves enormous respect in the PHP community. In fact, while designing and building Simple Data Objects, I was partly inspired by Spatie's own decisions — their attention to detail and excellent developer experience (DX).

spatie/laravel-data is an extremely powerful tool with deep integration into the Laravel ecosystem. If you need highly complex dynamic transformations, on-the-fly magic type resolution, or ready-made solutions for many Laravel-specific components out of the box — Spatie remains a great choice.

Simple Data Objects, on the other hand, was designed from day one under a completely different philosophy — it's tuned for uncompromising performance and low runtime overhead. If your hot paths (high-throughput APIs, queue workers, parsing large files, or data imports) suffer from noticeable CPU load and high memory usage — SDO offers a unique alternative. You get a strict, safe, and blazing-fast contract at a minimal execution cost.

Try it yourself!

All code examples, Docker configs, and the full test tooling live in a dedicated companion repository:

👉 simple-data-objects-benchmark on GitHub

You can fork it, run the benchmarks on your own hardware, or swap in your own payload shapes to see the difference in practice:

git clone https://github.com/std-out/simple-data-objects-benchmark.git
cd simple-data-objects-benchmark
make bench

We'd love to hear your feedback, pull requests, or a star on GitHub!

Package GitHub: std-out/simple-data-objects
Docs: Simple Data Objects Docs (or on Packagist)
Upgrading from v1? The changelog and migration notes are in CHANGELOG.md

What do you think of this approach to compiling DTOs in PHP? Share your experience in the comments!

Compiling PHP DTOs: from reflection to 4.5M hydrations per second

Yurii Zub — Sun, 12 Jul 2026 10:15:26 +0000

TL;DR: attribute-driven DTOs are pleasant to write but usually pay a reflection-and-dispatch tax on every call. Simple Data Objects compiles a specialized closure per data class instead — plain properties become inline array reads, the generated code is persisted into an opcache-served cache, and PHP 8.4 lazy ghosts defer hydration until first property access. Here's the architecture, step by step, with numbers at each stage.

Every modern PHP codebase eventually grows a layer of data objects: typed, immutable classes that sit between raw input (a request, a DB row, an API payload) and your domain logic. Attribute-driven DTO libraries made this pleasant to write:

class CreateOrderData extends BaseData
{
    public function __construct(
        #[Rules(['required', 'string', 'max:200'])]
        public readonly string $title,

        #[Cast(new DateTimeCast('Y-m-d'))]
        public readonly \DateTime $deliveryDate,

        public readonly ?string $notes = null,
    ) {}
}

$order = CreateOrderData::from($request->all());

But pleasant to write usually means expensive to run. The typical implementation reflects over the constructor, reads the attributes, and walks a generic hydration pipeline for every property of every object — on every call. That's fine for one DTO per request. It stops being fine when you hydrate a few thousand rows from a report query, or when your API serializes nested object graphs on every response.

I wanted the ergonomics without the tax. The result is a PHP 8.4+ package where the hot path contains no reflection, no attribute reads, and no generic dispatch loop — because by the time production traffic hits it, hydration is a compiled function.

Step 1: reflect once, not per call

The obvious first move: do all reflection up front. On the first from() call for a class, the package builds a ClassMeta — an immutable description of the constructor: parameter names, types, defaults, nullability, and everything the attributes declare (casts, input-key mappings, pipes, validation rules).

Every subsequent call reuses that metadata. This is table stakes — most libraries do some version of it — and it still leaves you with an interpreted loop: for each parameter, check "does it have a cast? a mapped key? a default?" and branch accordingly. Thousands of objects × dozens of properties = millions of predictable, redundant branch decisions per request.

Step 2: compile the loop away

The metadata is static per class. So instead of interpreting it on every call, the package generates a specialized closure per class and lets PHP execute that.

For the CreateOrderData above, the generated hydrator is essentially:

static function (array $d) use ($p, $pipes): \App\Data\CreateOrderData {
    return new \App\Data\CreateOrderData(
        \array_key_exists('title', $d)
            ? $d['title']
            : throw DataHydrationException::missingField(CreateOrderData::class, 'title'),
        \array_key_exists('deliveryDate', $d)
            ? ValueCaster::cast($p[1], $d['deliveryDate'])
            : throw DataHydrationException::missingField(CreateOrderData::class, 'deliveryDate'),
        $d['notes'] ?? null,
    );
}

Note what happened to each kind of parameter:

Plain properties (title, notes) became direct array reads. No pipeline, no dispatch — the nullable-with-null-default case collapses all the way down to $d['notes'] ?? null.
Properties with behavior (deliveryDate has a cast) delegate to the same runtime ValueCaster as before, with the metadata captured in use. Semantics are identical to the interpreted path; only the per-parameter "what kind of property is this?" decision is gone, because it was made once at compile time.
Missing-field errors are inlined as throw expressions, so the happy path carries no error-handling scaffolding.

The serializer side (toArray()) gets the same treatment: plain properties become inline property reads into an array literal.

"You're eval()-ing generated code?" Yes, once per class per process — and the generated source is assembled only from reflection metadata. Class and property names are valid PHP identifiers by definition; the single free-form string that can appear (an input key from #[MapPropertyName]) is embedded via var_export(). There is no path from runtime input into the generated code.

Result of this step alone, measured on the same DTO shapes: hydration ~2.6× faster, serialization ~2.2× faster than the interpreted pipeline it replaced.

Step 3: don't even compile at runtime

A compiled closure still costs reflection + code generation + eval() on the first call of each process. With PHP-FPM that's every worker after every deploy; with short-lived CLI jobs it's every run.

So the metadata cache persists the compiled code. Point the registry at a directory:

MetadataRegistry::setStoragePath(storage_path('framework/data-objects'));

and each class gets a .meta.php file containing the exported metadata plus the generated hydrator and serializer source. Loading it is a PHP include — which means opcache serves it as compiled opcodes, shared across all FPM workers. A warmed worker pays neither reflection nor eval(). The cache write is atomic (write-to-temp + rename), and a guard refuses to persist classes whose metadata isn't safely exportable.

Pre-warm on deploy so even the first request is hot:

vendor/bin/sdo-warm storage/framework/data-objects app/Data

The warmer scans your PSR-4 sources for concrete data classes, compiles everything, and fails the deploy fast if any DTO definition is invalid — which is exactly when you want to find out.

Step 4: don't hydrate what nobody reads

PHP 8.4 shipped lazy objects, and they're a perfect fit for DTOs. fromLazy() returns an uninitialized lazy ghost; the compiled argument resolver runs on first property access:

$orders = array_map(OrderData::fromLazy(...), $rows);

// casts, nested DTOs, pipes — none of it has run yet.
// Touch one property and that object (only) hydrates:
$orders[0]->title;

Both the eager hydrator and the lazy argument resolver are generated from the same code builder, so hydration semantics can't drift between the two paths.

When only ~10% of created objects are ever read — think "hydrate the page, render the visible rows" — this measures ~3× faster on cast-heavy DTOs and ~6× with nested collections. Honest footnote: for trivial flat DTOs the ghost bookkeeping costs about as much as it saves, so the docs say exactly that instead of pretending it's free speed.

And for the "million rows through a pipeline" case there's lazyCollection(), which hydrates one item at a time as the collection is consumed: streaming 50,000 rows peaks at ~0.26 MB instead of ~13 MB materialized.

The numbers

Benchmarked against the most popular full-featured data-object library in the PHP/Laravel ecosystem — identical DTO shapes, 20,000 iterations per scenario, PHP 8.4:

Scenario	Simple Data Objects	Popular alternative	Advantage
Hydration — flat DTO	~4,500,000 ops/s	~130,000 ops/s	~35×
Hydration — nested DTO	~2,200,000 ops/s	~74,000 ops/s	~30×
Hydration — collection of 20	~270,000 ops/s	~7,500 ops/s	~36×
Serialization — flat DTO	~7,400,000 ops/s	~200,000 ops/s	~37×
Serialization — nested DTO	~4,000,000 ops/s	~117,000 ops/s	~34×
Peak memory — 50k rows	0.26 MB (`lazyCollection()`)	~13 MB	~50× less

Absolute numbers vary with hardware; the ratios stay stable across runs. To be fair to the alternative: it does more — it's a framework-integrated toolkit with TypeScript transformers, wire formats, and a large extension surface. If you use that surface, use it; it's excellent. This package targets the case where DTOs are on your hot path and you mostly need hydrate/validate/serialize — the 80% — as fast as PHP can go.

What you give up

Design honesty section. The speed comes from constraints:

PHP 8.4 only. Lazy ghosts, property hooks-era engine. No polyfills, no legacy branches.
Constructor-promoted, readonly properties are the model. No setters, no mutable state — which is also just correct DTO design.
No runtime magic. Everything the DTO does is declared in attributes and compiled ahead of time. If you need to rewire behavior per instance at runtime, this is the wrong tool.

What you don't give up: validation (Laravel rules, working standalone without a Laravel app), casts (dates, enums, JSON, encrypted fields via libsodium), input pipelines, key transforms, nested collections, immutable with()/diff()/equals(). The test suite covers 100% of lines, enforced in CI — the coverage gate fails below 100, and there are no @codeCoverageIgnore escapes.

Try it

composer require std-out/simple-data-objects

std-out / simple-data-objects

Blazing-fast attribute-driven DTOs for PHP 8.4+ — compiled hydrators, zero reflection in production, works standalone or with Laravel

Simple Data Objects

Lightweight, attribute-driven DTOs for PHP 8.4+.
Works standalone or inside Laravel 10–13. No reflection in production.

composer require std-out/simple-data-objects

→ Full documentation

Why

Simple Data Objects
Hot path	Compiled per-class closures — zero reflection, zero dispatch overhead
Boilerplate	None — constructor props + attributes
Roundtrip	`from(toArray())` always works, mapped keys included
Standalone	Validation works without a Laravel app
Pipelines	Middleware-style input preprocessing, class or property level

Performance

Benchmarked against the most popular full-featured data-object library in the PHP/Laravel ecosystem — identical DTO shapes, 20,000 iterations per scenario, PHP 8.4:

Scenario	Simple Data Objects	Popular alternative	Advantage
Hydration — flat DTO	~4,500,000 ops/s	~130,000 ops/s	~35× faster
Hydration — nested DTO	~2,200,000 ops/s	~74,000 ops/s	~30× faster
Hydration — collection of 20	~270,000 ops/s	~7,500 ops/s	~36× faster
Serialization — flat DTO	~7,400,000 ops/s	~200,000 ops/s	~37× faster
Serialization — nested DTO	~4,000,000 ops/s	~117,000 ops/s	~34× faster

…

View on GitHub

Docs: https://std-out.github.io/simple-data-objects/
Good first issues (new casts, pipes, cookbook recipes): https://github.com/std-out/simple-data-objects/issues

If you try it on a real workload, I'd genuinely like to hear the numbers — especially where it doesn't win. Benchmarks that survive contact with other people's production are the only ones that matter.

DEV Community: Yurii Zub

Simple Data Objects v2: from a fast PHP DTO hydrator to a full Typed Data Boundary

Simple Data Objects v2: from a fast PHP DTO hydrator to a full Typed Data Boundary

1. Why plain arrays aren't enough anymore

2. Anatomy of a DTO in Simple Data Objects v2

3. Data boundaries and flexible usage scenarios

A. HTTP requests: fast fail-fast validation

B. Importing large files (CSV/JSON): error accumulation

C. Lazy typed collections

4. The SDO v2 feature map: everything in one place

Pipes for input cleanup

Built-in and custom casts

PATCH API: working with the Optional type

Contextual serialization: #[Hidden(except: [...])]

One contract for both backend and frontend (TypeScript)

5. Performance: numbers you can verify

Comparative benchmark: SDO vs spatie/laravel-data

CPU load and memory usage

6. Smart trade-offs

Try it yourself!

What do you think of this approach to compiling DTOs in PHP? Share your experience in the comments!

Compiling PHP DTOs: from reflection to 4.5M hydrations per second

Step 1: reflect once, not per call

Step 2: compile the loop away

Step 3: don't even compile at runtime

Step 4: don't hydrate what nobody reads

The numbers

What you give up

Try it

std-out / simple-data-objects

Blazing-fast attribute-driven DTOs for PHP 8.4+ — compiled hydrators, zero reflection in production, works standalone or with Laravel

Simple Data Objects

Why

Performance

PATCH API: working with the `Optional` type

Contextual serialization: `#[Hidden(except: [...])]`