1

I have a clean redistributable model that contains a lot of derived classes. Just to be clear, see the example below.

class Foo
{
...
}

class BarA:Foo
{
...
}

class BarB:Foo
{
...
}

In order to deserialize those classes from Json to the correct class (e.g. BarA, instead of just Foo), I created my own converters by inheriting JsonConverter. It works perfect for my application, but this requires that others using this library to write their own converters. I don't want to include the converters to my model, because that would create a dependency to JSON.NET and from there hell breaks loose when projects in the solution using it have different versions of JSON.NET.

Is there any clean way to do this, without polluting the pure .NET model?

Midas
  • 564
  • 6
  • 21
  • 2
    Can you show us how you pollute those POCOs? And why you need custom converters with some example. – Eldar Dec 02 '19 at 08:11
  • 2
    _"...hell breaks loose when projects in the solution using it have different versions of JSON.NET..."_ - unless you are using child AppDomains or Json.net is _strong-named_, your primary AppDomain (your process) _already_ has a direct dependency to a certain version of Json.net so attempting to avoid a static code dependency sadly won't help. –  Dec 02 '19 at 08:11
  • @Eldar The moment I import JSON.NET to my redistributable. Preferably, I don't want my POCOs to know anything about JSON.NET. – Midas Dec 02 '19 at 08:38
  • Your POCOs don't have any dependecy on JSON.Net if you don't use the serialization attributes. (You don't do this at least in your OP). You can pass the list of available converters to the Deserialize method when you call the deserializer. You can wrap your dependency on JSON.Net in a service, but you will always have some kind of dependency on JSONConverter outside your POCOs – Georgi Georgiev Dec 02 '19 at 09:13
  • You can move the serialization attributes to another class with the [MetadataType attribute](https://stackoverflow.com/q/45045546/11683) to make the data classes look clean, but even then you retain a dependency to JSON.NET somewhere. You just move that *somewhere* around. – GSerg Dec 02 '19 at 09:17
  • @GeorgiGeorgiev, that is fine with me. I just don't want to have any dependency inside the POCOs. – Midas Dec 02 '19 at 09:31

2 Answers2

1

Your POCOs don't have any dependecy on JSON.Net if you don't use the serialization attributes. (You don't do this at least in your OP). You can pass the list of available converters to the Deserialize method when you call the deserializer. You can wrap your dependency on JSON.Net in a service, but you will always have some kind of dependency on JSONConverter outside your POCOs

Pseudo C#

JsonConvert.DeserializeObject<YourPOCO>(yourJsonString, new YourFancyConverter())

API docs

Georgi Georgiev
  • 3,854
  • 5
  • 29
  • 39
0

Based on Georgi Georgievs answer, I created a separate service library that handles all deserialization by picking the right converter. This library has an advantage, but also a flaw:

  1. Applications that want to use the model can deserialize without the need to write any extra code or logic to handle the deserialization process.
  2. The POCO model has no dependencies except the System namespace.
  3. The service library has a dependency on JSON.NET. If that is an issue, the developer can still choose to write his/her own converter. However, the POCO model will still be usable, which would not be the case if I had a dependency to JSON.NET inside the POCO DLL.
Midas
  • 564
  • 6
  • 21