Reply content:
The Laravel framework uses a large number of traits. Give me a few examples.
Trait was used in eloquent. Then, when the model is initialized, there is a boot method that automatically determines which trait the current class uses. And then get an array. The program iterates through the array, looking for any method that conforms to the "boottraitname" (defined in trait) and executes if there is one.
Eloquent in this way, when you initialize a model, you can do many automatic loads, such as events. In its own function, Softdelete is doing so. Simply put, using the model of Softdelete, will automatically execute the Bootsoftdelete at boot, then all queries of the model are added by default to a link to determine the Deleted_at field, in order to only extract data that has not been deleted.
This approach provides a lot of convenience (imagine loading a cachable trait, adding an event to the model each time the boot is made, and automatically generating a cache once a record has been modified).
Trait is also used frequently in other scenes of Laravel. For example, the user model is the driver that Laravel uses to authenticate. The method associated with authentication is loaded with a trait. There are laravel out of the box to bring the Authcontroller, but also to retrieve the password and other functions made trait. So when we need to switch to another controller to do the verification drive, just write a line of use code, we automatically get the relevant method.
Laravel use of trait there is a more typical, is dispatch. This trait was called primarily in the controller of the Laravel. This allows the Laravel controller to dispatch tasks directly with $this->dispatch (). Furthermore, any class that uses the Dispatchjob trait can use the same scheduling method (which actually uses the app () to get a dispatch singleton).
I do not know whether the above answer satisfies the main question. Use traits as model, do not know if there is a problem?
It hasn't been done yet.