Using the same data for read, create and update

[bentleyo]

Hi there,

I'm trying to use the same data object for CRUD actions in my application and I feel like the pattern I'm using is a little awkward. In particular, dealing with id fields and ids of related models .

• When creating a new model from a data object you won't have an id attribute
• When editing the model you don't want the id to be provided at all
• When reading the model it needs to be there

At the moment I'm solving this by doing something like:

class PostData extends Data
{
    #[Prohibited]
    public int|Optional $id;

    public function __construct(
        #[Required, Max(255)]
        public string $title,
        #[Required, Max(255)]
        public string $description,
    ) {
        $this->id = Optional::create();
    }
}

This way I can still use the model constructor to create data in my tests. However, I feel like this feels a little awkward and in some more complex models I find myself needing to add more attributes as optional and prohibited.

I feel like one approach could be to split the data model up into a read object, create object and update object. In the laracon video Freek showed an example of something like this with a data object at the path: \App\Http\App\Requests\Project\CreateProjectData.

This makes it clearer that what is going to be validated and makes it easier to prevent some fields from being specified on update. However, this creates another problem which is potentially duplicating a lot of the validation rules with bigger objects.

How do you guys approach this problem?

[rubenvanassche]

Took a look at the project we've created this package for. In this case we make a more 'traditional' split. So we have data objects being used for create and update without the id. And we have a resource object which is used for the show views with an id and probably a lot of other information which is not required with the data create/update views like the id.

So each entity has 2 data objects: the real data object and a resource with a lot more info.

Another solution you could look at is using inheritance, but maybe that will complicate things even more.

[jesseschutt]

Took a look at the project we've created this package for

Hey @rubenvanassche - Which project are you referring to?

[gregupton]

https://github.com/spatie/laravel-data-demo

[jesseschutt]

Thanks @gregupton - I can't seem to locate any places in that repo where it utilizes data objects though. What am I missing?

[gregupton]

Yeah, I think this is more of an example of using request/resources for CRUD actions.

[rubenvanassche]

This is a client project of ours, nothing open source. The demo project is created by Freek for a conference talk but is indeed missing examples like you mentioned.

[denjaland]

For what it's worth - we played a lot with it too, and in the end decided to split it and create separate Data objects for their individual contexts. Makes the validation rules much clearer, but of course still requires you to maintain all these Data objects in case you add an attribute to a model for instance.

[expertcoder]

I'm facing the same problem, at the moment I am using something like

class ProductCreateDto extends Data
{
    public function __construct(
        public string $name,
        public string $description
    )
    {  /** ...  */  }
}

class ProductUpdateDto extends Data
{
    public function __construct(
        public string|Optional $name,
        public string|Optional $description
    )
    {  /** ...  */    }
}

For a create operation, both name and description are required, but for a "patch/update" its possible that only the name will be updated but not the description, so for ProductUpdateDto name and description are Optional.

However in the real world these DTOs have about 30 properties each, and I think it will be very messy to duplicate the properties in two or potentially more classes.

I also considered something like this

class ProductCreateDto extends Data
{
    public function __construct(
        public string $name,
        public string $description
    )
    {  /** ...  */  }
}

class ProductUpdateDto extends ProductCreateDto
{
    public string|Optional $description;
    /**
     * ...
    Here only change the properties that need to be different
     */
   
}

But this violates PHP inheritance, the child class is not allowed to change the property type from the parent.

Happy to hear any suggestions on this topic.

[Mohammed-Alama]

I have the same issue and have been looking for answers in other frameworks
and I have found this on nestjs https://trilon.io/blog/introducing-mapped-types-for-nestjs
so I was wonder if we have annotation on the Data class it self the use the create structure (which is all attributes is required)
and modify it behaviour based on the annotation