Is your feature request related to a problem? Please describe.
Currently, parsing, type conversion and JSON conversion all rely on IIbanParser which in turn relies on IIbanValidator which in turn relies on IIbanRegistry and IIbanValidationRule. We can simplify this, by decouple parsing/conversion from validation, and instead take a direct dependency on IIbanRegistry.
The effect is that custom validation will no longer be used during parsing/conversion. While this is a behavioral change, the custom rules were originally designed to run additional business logic on user input. The use case for parsing/conversion rather is to serialize/deserialize a previously validated IBAN. Having to rerun validation logic every time is unnecessary in the latter scenarios, and it is thus better to move this responsibility to the implementor of IbanNet.
Describe the solution you'd like
[ ] Introduce a static member IbanRegistry.Current or IbanNetConfig.CurrentRegistry of sorts which allows users to set/override the registry (eg. to add the WikipediaRegistryProvider). This property must be automatically configured for the user when dependency injection is used.
[ ] The parser/converters are refactored to use the static member from previous bullet, when no dependency injection is used. If dependency injection is used, we resolve the IIbanRegistry from the DI container.
[x] As intermediate step, the parsers/converters may use IbanRegistry.Default
[ ] Remove IbanValidatorOptions and refactor/simplify dependency injection configuration extensions. The current registration extensions are strongly biased towards validation (dating back to when that was the only thing IbanNet offered). Custom rules and custom registry providers should from here on out be manually registered in the DI container. These are for more niche use cases which don't warrant the maintenance burden.
[ ] Custom (validation) rules will only be used for validation and are no longer considered for parsing/conversion.
[ ] Once this is all done, we can internalize the parser implementation, such that we can use ReadOnlySpan<T> more consistently, and shift the public API use to IParsable<TSelf> and ISpanParsable<TSelf> on the Iban type directly. (related to #133)
Challenges
We have to consider both non-DI an DI use cases, which complicates the matter a bit.
This is a breaking change, as this changes the behavior of parsing/conversion and requires some public API changes.
Is your feature request related to a problem? Please describe. Currently, parsing, type conversion and JSON conversion all rely on
IIbanParserwhich in turn relies onIIbanValidatorwhich in turn relies onIIbanRegistryandIIbanValidationRule. We can simplify this, by decouple parsing/conversion from validation, and instead take a direct dependency onIIbanRegistry.The effect is that custom validation will no longer be used during parsing/conversion. While this is a behavioral change, the custom rules were originally designed to run additional business logic on user input. The use case for parsing/conversion rather is to serialize/deserialize a previously validated IBAN. Having to rerun validation logic every time is unnecessary in the latter scenarios, and it is thus better to move this responsibility to the implementor of IbanNet.
Describe the solution you'd like
IbanRegistry.CurrentorIbanNetConfig.CurrentRegistryof sorts which allows users to set/override the registry (eg. to add theWikipediaRegistryProvider). This property must be automatically configured for the user when dependency injection is used.IIbanRegistryfrom the DI container.IbanRegistry.DefaultIbanValidatorOptionsand refactor/simplify dependency injection configuration extensions. The current registration extensions are strongly biased towards validation (dating back to when that was the only thing IbanNet offered). Custom rules and custom registry providers should from here on out be manually registered in the DI container. These are for more niche use cases which don't warrant the maintenance burden.ReadOnlySpan<T>more consistently, and shift the public API use toIParsable<TSelf>andISpanParsable<TSelf>on theIbantype directly. (related to #133)Challenges