Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Problems with AddAdoNetStorageProvider() extension method #3088
The AddAdoNetStorageProvider() method:
Since changing the default value of a parameter is generally a bad idea, I suggest deprecating this method altogether.
@veikkoeeva I am not sure what you are pointing out in the link you shared, as the referenced code does not use XML as default.
The point here is that it is a breaking change for application code to switch between
I understand that binary as default is a bad idea, but having different defaults is worse in my opinion. This is confusing and error-prone for people using these APIs.
The new IoC would also mean ADO.NET provider does not need to take dependency to any of the current methods as anything the developer wants to can be loaded via the IoC. Technically, internally, currently an enumeration is used and based on that a serializer-deserializer pair is chosen that use a common interface. This could be reworked so that the user now directly choose the component used.
There are a few other API issues to think of too.
referenced this issue
Feb 2, 2018
@ReubenBond I don't have a definite answer yet. I'm frankly over-extending myself a bit currently so I need a bit to think about this. If it helps, I would want to have easy and visible defaults to configure XML and JSON with defaults and customer settings. I would also want to have a way to easily expose the current canonical (de)serializers and see if the API surface is clear enough to communicate:
The goal for 1., 2., and 3. is to make way for one to make it easier to mix and match (de)serialization decisions with great granularity. This will help fix "data bugs", refactor "data schema" (after all, even XML with a Schema would need to evolve at some point, or JSON without schema) and evolve the data in such ways as changing the storage format (e.g. make something more amenable to in-storage processing while compression some to "cold storage").
I think the current APIs work pretty much as-is currently, but it would be great if some things, such as (de)serializers together with the container would be injected and maybe refactored if there are ideas. Especially the logic to choose a (de)serializer from the container I'd like to ponder a bit more than I did, but I suppose it's not on the core mainter roadmap, so I'm happy to do that later myself later if it's not completely out of picture. :)