- How do I install zero-to-prod/data-model in a Laravel application?
- Install it with composer require zero-to-prod/data-model and confirm the package's composer.json PHP constraint matches your runtime. Adoption is minimal: add the DataModel trait to any class, with no base class or interface to extend. No service provider registration is required for basic hydration, so the same DTOs work in plain PHP services as well as Laravel apps.
- Which Laravel and PHP versions does data-model support?
- DataModel is framework-agnostic and does not pin a specific Laravel release; it relies on PHP 8.1+ features such as attributes and union types. In practice it runs on any Laravel version whose PHP requirement your application already satisfies. Always check the package's composer.json constraint before upgrading a mixed-version fleet.
- How does from($data) hydrate nested DTOs and arrays of DTOs?
- from($data) recurses into nested arrays and collections when a property's type hint points at another DataModel class. That lets you map an API response containing nested objects, or a list of child DTOs, in a single call. Deep nesting adds reflection work, so benchmark payloads with heavy object trees before adopting on critical paths.
- What does the #[Describe] attribute do and which options does it accept?
- #[Describe] sits above a property and carries flags such as required, nullable, default, and assign, along with casting behaviour. It keeps validation, casting, and nullability decisions colocated with the property declaration instead of scattered across constructors, factories, and services. Missing required values and null handling are resolved by the attribute rather than repeated isset guards.
- Can I hydrate DataModel DTOs from Eloquent models or query results?
- Yes. Map Eloquent results into DTOs, for example Model::query()->get()->map(fn ($m) => User::from($m->toArray())). Be aware that accessors, mutators, hidden fields, and lazy loading change what toArray() emits, so hydrate from explicit attributes when those behaviours matter. Eager loading and query-level optimizations still belong in the Eloquent layer.
- Is data-model fast enough for hot paths and large collections?
- Hydration uses reflection and attribute parsing, which adds overhead compared with hand-written constructors. The v81.20.0 optimization work targets that reflection and hydration path and materially lowers the risk flagged in earlier assessments. It does not eliminate it, so benchmark your own payload shapes, nesting depth, and collection sizes before retiring manual hydration on critical paths.
- Does data-model use Laravel's Validator for validation?
- No. DataModel's validation is declarative and colocated in attributes; it is not a wrapper around Laravel's Validator. Teams that need Laravel's rule set typically keep a FormRequest at the boundary or build a bridge through DataModelHelper so rules are not duplicated. Decide up front which layer owns validation to avoid drift between the two.
- Do I need PHP 8.5 to use closure literals inside #[Describe]?
- Closure literals as attribute parameters are a PHP 8.5 language feature, but the change is additive: existing #[Describe] usage still runs on PHP 8.1 through 8.4. The risk is that any class adopting inline closures becomes unrunnable on older runtimes. Confirm the package's declared PHP constraint and your fleet's minimum version before using the new syntax.
- How does data-model compare to spatie/laravel-data or manual constructors?
- Common alternatives include spatie/laravel-data, hand-written constructors and factories, and Laravel's own form requests and API resources. DataModel's differentiator is a single from($data) call with attribute-driven casting, defaults, and nullability, without requiring a base class or interface. Choose based on how much of your DTO behaviour you want living in attributes versus service classes.
- Is data-model actively maintained and how should I test my own DTOs?
- The package ships its own test workflow plus a backwards-compatibility check, and v81.20.0 adds coverage for #[Describe] parameter handling, which is a positive upgrade signal. That coverage does not replace consumer-level contract tests on your own DataModel classes. Assert hydration of required, nullable, default, and nested properties in your application's suite.