-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic entity/object lookups #13
Comments
Hi @iainmckay , sorry for the delay, |
This is roughly what we're running to create the bindto service: https://gist.github.com/iainmckay/6ef89477aa1efe29bbefb582b1fc3df5 |
If the |
@iainmckay I like it... |
Cool. We can either merge it in to Bindto or setup another project (e.g. Bindto-extensions) if you want to keep the main project slim. Tests also need to be written. |
I really like to see this finished... |
👍 💯 |
What do you mean by deal with collection? |
Maybe after this, the next biggest feature is when you have complex objects with arrays and staff like this... |
Ah yes, we don't have this problem at the moment but it should be fairly straightforward to support lists. If you want to review the PR I added, I'll incorporate any changes you think should be made and write some tests. |
Great! |
I updated the PR with collections and some other usability improvements. I also have an ObjectConverter which invokes the binder so you can have arrays of transfer objects converted waiting to be commited. We're just testing it some more internally. Here's an example from our codebase:
Transfer objects:
This recursively converts the input values of $records to instances of |
I'd like to open a discussion on a new piece of functionality we need in our app. I provide a rationale and some possible solutions.
Feedback would be appreciated before I start implementing this.
Intention
To provide an automatic system for resolving object references to instances.
Our service layer accepts a lot of commands/dto's which contain references to entities or value objects in our domain. We have a lot of repetitive lookup code that we would like to get rid of.
It is essentially the functionality provided by Symfony ParamConverter but without the requirement to pass a Request object.
This feels very much like reinventing the wheel when there is a battle tested implementation that already exists but we've discussed it internally and don't see a way around it.
Basic Use
This would work similarly to PR #11 in that you would annotate a property on a DTO. The binder would then create an instance of the registered converter to produce an object instance. If the conversion process fails a violation would be added to the violation list.
The converter would accept the object identifier and convert it by whatever means necessary to an instance of that object or fail trying.
Possible Solutions
I provide two possible solutions for making this feature work.
Example 1
In this example the naming and documentation of the properties are as if they are already instances. It is the most natural but may be a little confusing for the developer dispatching the DTO to the service layer as we're passing in object identifiers but the documentation (and auto-complete) says instances.
Example 2
In this example the naming and documentation of the properties are more obvious for the consumer as to what the expectations on the service consuming the DTO are. Accessing the converted objects is more obtuse and lacks support for autocomplete.
Converters
A converter would follow a very simple interface and would be registered with the Binder to be made available.
The text was updated successfully, but these errors were encountered: