-
Notifications
You must be signed in to change notification settings - Fork 45
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
Enables the generation of converters in other projects #541
Comments
A great suggestion. I too use onion/clean architecture. I enforce constraints using the fantastic NsDepCop (https://github.com/realvizu/NsDepCop) which inspects namespace references for violations. |
Nice to know about your interest in implementing the feature. The implementation is open-sourced here: https://github.com/dotnet/runtime/tree/c08faf9216976a14f06a11373fbd3aec7671bf7a/src/libraries/System.Text.Json/gen I haven't spent time on source generators deeply (and I'm out of time to do that anytime soon), so I can't implement a PR myself, but I'll be willing to test it out once it's ready to be tested. |
@SteveDunn Hey Steve, you must be busy, so sorry to tag you! But any updates on this one? I just started using Vogen and this is the first problem I encountered, pretty annoying...! |
Hi @xamir82 - I'm taking a look now, although it'll be a fairly big change, so might not arrive for a while |
There are a few issues with implementing this:
With this in mind, rather than loosening the constraints of value objects, I feel it would be better to use another mechanism to prohibit the use of infrastructure code from the domain layer. NSDepCop is ideal for this, and it's something I use. Not only does it mean that you don't have to have separate projects (and using circular dependencies as a safety net), it means you have finer grained control. Here, you prohibit I wanted to close this ticket, but I'll leave it open to see if there's any approaches I've missed. |
Thanks for the detailed description on how you do it @MithrilMan . One of the things that Vogen did was to throw exceptions in the But thanks again, and I'm glad you can now use the goodness of value objects in the domain and infrastructure where it should be! 👍 |
@SteveDunn Hey Steve, to quickly chime in: That's not the case. This sort of scenario was precisely why So, you don't have to make any private member public in order to implement this functionality; you can take advantage of this new .NET 8 feature to source-generate a converter that accesses any private member of the value object from the outside with no overhead. Correct me if I'm wrong, but please consider reopening the issue. |
Thank you @aradalvand - that looks really interesting! I'll take a look at that right now and update this thread shortly. |
I should have a build ready over the weekend. The |
This was released in 4.0.9 - thanks for the input! |
Describe the feature
Following clean architecture you usually split domain from infrastructure.
Persistence implementation lives in the infrastructure project so any EntityFramework/Dapper converter must be generated there.
This mean that it's not viable to use type converter in the value object definition (Domain project) because I don't want to add persistence dependency on that project.
Would be useful to have a source generator that generates converters for generated value objects.
I could imagine an API like this (less verbose maybe...)
That would generate a converter for CustomerId and OrderId
this could be implemented more generically with a ValueObjectConverter where you pass the converters you want to be generated (e.g. using the enum you already have).
The text was updated successfully, but these errors were encountered: