Originally, I created the HaveIBeenPwnedClient as a facade/factory class for when multiple IHaveIBeenPwnedClient implementations would be added. But realistically, we will only have the HTTP implementation in the foreseeable future unless HaveIBeenPwned.com significantly changes the way it works and we can't predict that so, whatever. It was just my fault of overengineering this.
Currently, having HaveIBeenPwnedClient just passing all calls to HttpHaveIBeenPwnedClient is becoming more and more of a burden. Using it in .NET Core's DI system is hard because that will always call the most specific constructor (the one with the IHaveIBeenPwnedClient). So in the end you just register HttpHaveIBeenPwnedClient for DI and not bother with HaveIBeenPwnedClient at all. Also, we now have to do a lot of unit testing etc. for something that doesn't serve any real purpose.
So, we're going to replace the business logic of HaveIBeenPwnedClient with HttpHaveIBeenPwnedClient.
Originally, I created the
HaveIBeenPwnedClientas a facade/factory class for when multipleIHaveIBeenPwnedClientimplementations would be added. But realistically, we will only have the HTTP implementation in the foreseeable future unless HaveIBeenPwned.com significantly changes the way it works and we can't predict that so, whatever. It was just my fault of overengineering this.Currently, having
HaveIBeenPwnedClientjust passing all calls toHttpHaveIBeenPwnedClientis becoming more and more of a burden. Using it in .NET Core's DI system is hard because that will always call the most specific constructor (the one with theIHaveIBeenPwnedClient). So in the end you just registerHttpHaveIBeenPwnedClientfor DI and not bother withHaveIBeenPwnedClientat all. Also, we now have to do a lot of unit testing etc. for something that doesn't serve any real purpose.So, we're going to replace the business logic of
HaveIBeenPwnedClientwithHttpHaveIBeenPwnedClient.