Deserialisation in C#

Domain-Driven Design
21

:+1:
reactive-domain is a toolkit more than a framework,
It is in production in a number of places, but I’ve not really had a chance to document it as I’d like.
Feel free to drop any questions you have here.

This will try to find the type via reflection “automagically” :slight_smile:

22

My two cents there. I am not using any kind of reflections and magic in production applications for a while now. I do use what @steven.blair called a “simple dictionary”, which maps names to types and types to names. Essentially, it is a reversible mapping.

Cons:

  • Need to map each new event type. But it’s easily an catch for tests, if you forget to map

Pros:

  • Interoperability (no namespace dependency, etc) compared with FQTN
  • Easy to fix typos and awkward names in code, leaving already stored events intact
  • Easy versioning - adding V1 in code doesn’t need to touch already stored events
  • Follow up - no ambiguity, if the event type name is the same, you map it in a way you want
  • Type resolution speed
  • Making implicit explicit

It’s just what comes to mind straight away, but we struggled a lot with reflections and never had issues after moving to explicit mapping.

And here’s a simple version https://github.com/alexeyzimarev/dotnext/blob/master/src/DotNext.Lib/TypeMap.cs, which is enough for 99% of cases, except you might to have it not as a singleton if you have a few contexts in one app.

2 Likes
23

Alexey,

This looks pretty cool.
I will plug it in and see how we get on.
The Assembly loading is working well for us just now as well, so I guess we will need to decide which route to take.

24

It does work, yes, and still we have seen often that FQTN effectively prevents you from evolving your model and use a (even slightly) different language. Just type names can easily get conflicted when you have V1.SomethingHappened and V1.SomethingHappened. Of course, one could use SomethingHappenedV2, but it brings the versioning semantics right to your face, which I personally don’t like.

25

The “simple dictionary” is a good approach as well.
The interface based design is there to allow to upgrading to this type of approach or injecting thing like transforming or binary serializers as you are not always serializing to and from storage.

Also while the r-d serializer can support fully qualified names it defaults to simple names in the local assembly first. This avoids the upgrade pain of the FQDN, which is a thing.