The Json.Net contract resolver that's first passed to JsonPatchDocument's constructor is then passed among numerous methods and objects throughout the code. Three problems relate to this.
The serializer's contract resolver is often not the one passed in. When JsonPatchDocument's parameterless constructor is called, it defaults to passing new DefaultContractResolver() for the contract resolver. Even if the library user provides one via another constructor, he'll probably opt for the easy new DefaultContractResolver() instead of pulling one from the serializer. As for patch docs deserialized by Asp.Net Core, JsonPatchInputFormatter only works for JsonPatchDocument's generic version due to this line.
JsonPatchDocument constructors don't allow a null contract resolver. The parameterless constructor will use new DefaultContractResolver(). The constructor that accepts a contract resolver throws ArgumentNullException if it's null. This doesn't make sense for scenarios that never use a contract resolver. None of my scenarios require a contract resolver, and usages in the library could be replaced by reflection or left to customization by other means. For example, the usage here can be replaced with targetObject is and reflection. It's used to allow customization of how a path segment resolves to a dictionary key here and allow customization of how a path segment resolves to a dynamic property name here. Those uncommon customizations can be accomplished by other means like modifying the path segments before calling ApplyTo or customizing the overall ApplyTo behavior. That property usage is also haphazard since it's used there but not here. Anyway, I digress.
The contract resolver appears as a parameter in all of IAdapter's methods and their implementations. This makes the various method signatures of IAdapter and its implementations unnecessarily verbose, and thus harder to understand and cumbersome to use.
Make optional the contract resolver parameter of JsonPatchDocument's constructor. Don't throw an exception if it's null.
Eliminate all those IContractResolver method parmaters in IAdapter. Instead, have each IAdapter implementation that wants to use a contract resolver just have its constructor accept it.
The Json.Net contract resolver that's first passed to
JsonPatchDocument
's constructor is then passed among numerous methods and objects throughout the code. Three problems relate to this.JsonPatchDocument
's parameterless constructor is called, it defaults to passingnew DefaultContractResolver()
for the contract resolver. Even if the library user provides one via another constructor, he'll probably opt for the easynew DefaultContractResolver()
instead of pulling one from the serializer. As for patch docs deserialized by Asp.Net Core,JsonPatchInputFormatter
only works forJsonPatchDocument
's generic version due to this line.JsonPatchDocument
constructors don't allow anull
contract resolver. The parameterless constructor will usenew DefaultContractResolver()
. The constructor that accepts a contract resolver throwsArgumentNullException
if it's null. This doesn't make sense for scenarios that never use a contract resolver. None of my scenarios require a contract resolver, and usages in the library could be replaced by reflection or left to customization by other means. For example, the usage here can be replaced withtargetObject is
and reflection. It's used to allow customization of how a path segment resolves to a dictionary key here and allow customization of how a path segment resolves to a dynamic property name here. Those uncommon customizations can be accomplished by other means like modifying the path segments before callingApplyTo
or customizing the overallApplyTo
behavior. That property usage is also haphazard since it's used there but not here. Anyway, I digress.IAdapter
's methods and their implementations. This makes the various method signatures ofIAdapter
and its implementations unnecessarily verbose, and thus harder to understand and cumbersome to use.I propose solving these problems as follows.
JsonPatchDocumentConverter
. Then eliminateJsonPatchInputFormatter
too, which doesn't work for untypedJsonPatchDocument
s anyway.JsonPatchDocument
's constructor. Don't throw an exception if it'snull
.IContractResolver
method parmaters inIAdapter
. Instead, have eachIAdapter
implementation that wants to use a contract resolver just have its constructor accept it.