Closed MovGP0 closed 9 months ago
I can understand why you want it, but I'm not very inclined to add it, as otherwise why not allow it for ints, longs, all the other types. Where's the line? Why not also new CustomerId(byte[])
etc. Also, where is that string coming from? IMO you ideally should be using a converter to go directly from your source to the ID rather than through the string intermediate step
why not allow it for ints, longs, all the other types.
those base types don't have a constructor of type T(string)
; they use parse
/tryparse
functions instead that we might want to implement instead.
Why not also
new CustomerId(byte[])
etc.
Good idea.
Also, where is that string coming from?
I have the issue with migrating existing unit tests.
IMO you ideally should be using a converter to go directly from your source to the ID> rather than through the string intermediate step
Using the converter would be even more code in the unit tests then using the existing constructors.
If you have to migrate a lot of unit tests, it might be a symptom of poorly written fixtures, that could need improvement.
But other than that, i do agree that it's nice to have the direct constructor to make the API of the Ids more userfriendly.
If you have to migrate a lot of unit tests, it might be a symptom of poorly written fixtures, that could need improvement.
In my case it's a poorly written SQL database, where almost every table uses a GUID as the primary key.
For feature requests like this, I think I've found an answer in the big redesign of the library in this PR:
The main idea is to make the library much more maintainable while also giving people a mechanism to customise the generated IDs as much as they like. This will make it easy to make changes like this 🙂
When implementing a type like
Then instead of
I want to write