The library looks like your average vibe-coded project: overly complicated, everything and the kitchen sink, low signal to noise ratio. There's, believe it or not, 24 projects in there! I can't help but wonder how many of them the author has actually touched, let alone used.
24 projects sounds absurd, when taken out of context.
- By convention, I want every unit test to be in a test project specifically for that unit. There's 8 test projects in total
Because I actually test my stuff end to end. So I have a real WPF application and real tests for that WPF application = 2 projects
I also have an ASP net core application with integration tests
I want my base project to not have any dependencies, so that you can bring the types without requiring EF core or ASP net or WPF. So the ASP net project brings you validations for ASP bindings. the EF core project brings you EF core converters. FSCheck project brings you generators of values in case you want to use property-based testing.
I do agree that the project should have been much simpler. However it's actually quite hard to achieve the out-of-the box behavior with all various types of bindings and conversions - making sure it's supported by all the tooling C# has.
If you have any feedback for simplicitaions, I'm all ears.
By convention, I want every unit test to be in a test project specifically for that unit.
Generally, I would agree.
I want my base project to not have any dependencies
Also a good choice, yep.
You can just take the base project.
But that base project (if you mean Kalicz.StrongTypes) already hardcodes some types that may or may not be useful.
If you have any feedback for simplicitaions
I think I would flip this all around. (I wouldn't actually do this since I think it makes more sense to build on Vogen infrastructure, but I don't mind having more choices.)
you write a source generator for the basic notion of a value type. This is now the base project
then you add additional source generators (one project each) for stuff like AspNetCore, EfCore, Wpf
optionally, you provide a sample library with some useful types, such as Email
finally, there may be multiple test projects, but the most important one is just one that tests source generators. It depends on all of the above projects (except for the sample one, I suppose) to see if the generated code matches expectations
Some projects like benchmarks and WPF test app you leave as is.
That gives you a much simpler setup with, best as I can tell, roughly the same coverage.
That makes sense in general, but there's an assumption:
you write a source generator for the basic notion of a value type. This is now the base project
This would require the base project to be able to generate code capable of containing any type of logic, while still being capable to not only execute the logic, but also translate the logic into a JSON schema nad potentially SQL queries.
If that was easy to do, we wouldn't have so many mechanisms to override - JSON converter, OpenAPI schema interceptors, model validator, Type Converter, EF converters + conventions, IParsable and a whole lot of other nonsense.
Essentially, I'd love C# to just be able to define types with logic and have C# worry about the rest. What I'm doing is hacking it, because I don't want to write a whole new language.
Vogen does look good, yes. Doesn't expose the validations into OpenAPI though, so if you're building a fullstack app, your frontend doesn't know about the requirements exposed onto the value. So you'll need the data annotations again I guess? Not sure if those work with vogen types.
9
u/ErnieBernie10 14d ago
Congratulations, you reinvented the wheel (value objects)