You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working on a system that is using a bunch of Laravel subtree components, including the container, but is also not a full Laravel installation. In our controller methods, we're using lots of bespoke DTO objects which expect the Request in the constructor, and then pull out/sanitise the data we want. We can then inject these directly into our controller methods, and the container can build them automatically because it has the Request already.
When it comes to testing, though, it feels a bit clunky to have to build a fake request from an array of data, to build the DTO, to then turn it back into an array in the method; what would be nice is if the DTO used nice constructor promoted properties, and had a static named constructor such as public static function fromRequest(Http\Request): static;
so that we can create it directly in the constructor with the data for testing, and from the Request for injection.
That's fine in principle, but in practice, even if I put the fromRequest() signature onto a shared interface, the container doesn't know how to build the class.
Is there any way I can register a ServiceProvider for any class that implements an interface (but when requested by the classname, not the interface name), so that if I ask for a Child\DTO, the controller says "ah, I can't build Child\DTO directly, but it implements a construction interface that I know how to build, so I'll use that service provider"? That way, I can have lots of DTO classes, without having to register each one in the ServiceProvider, I can just apply the interface.
Alternatively, is there any nice way to intercept the container's auto-building do add in a bit of extra resolution logic, where I could put this, without completely changing the container?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
I'm working on a system that is using a bunch of Laravel subtree components, including the container, but is also not a full Laravel installation. In our controller methods, we're using lots of bespoke DTO objects which expect the Request in the constructor, and then pull out/sanitise the data we want. We can then inject these directly into our controller methods, and the container can build them automatically because it has the Request already.
When it comes to testing, though, it feels a bit clunky to have to build a fake request from an array of data, to build the DTO, to then turn it back into an array in the method; what would be nice is if the DTO used nice constructor promoted properties, and had a static named constructor such as
public static function fromRequest(Http\Request): static;
so that we can create it directly in the constructor with the data for testing, and from the Request for injection.
That's fine in principle, but in practice, even if I put the fromRequest() signature onto a shared interface, the container doesn't know how to build the class.
Is there any way I can register a ServiceProvider for any class that implements an interface (but when requested by the classname, not the interface name), so that if I ask for a Child\DTO, the controller says "ah, I can't build Child\DTO directly, but it implements a construction interface that I know how to build, so I'll use that service provider"? That way, I can have lots of DTO classes, without having to register each one in the ServiceProvider, I can just apply the interface.
Alternatively, is there any nice way to intercept the container's auto-building do add in a bit of extra resolution logic, where I could put this, without completely changing the container?
Beta Was this translation helpful? Give feedback.
All reactions