[RossStewart]

No description provided.

[lewisrenfrew]

This is better than the extensions approach from before, but we are still forcing consuming code to handle 'raw' messages and then remember to construct a JsonMessage from the raw message to access the new Body property, which is sort of just as much boilerplate as doing the deserialization themselves or calling the previous extension method.

After reminding myself how the publishing side works, I reckon a better approach is one that is symmetrical to that one - on that side I wrote a JsonMessagePublisher that wraps the raw RabbitPublisher, and so hides serialization from the caller entirely.

We could do the same on the consuming side with an abstract JsonMessageHandler of T that implements IMessageHandler, handles deserialization internally, and exposes a strongly-typed HandleAsync method for subclasses to override. That way the consuming service never touches raw messages or worries about deserialization at all - we can just call the JsonMessageHandler's HandleAsync which keeps things nice and clean.

[RossStewart]

This is better than the extensions approach from before, but we are still forcing consuming code to handle 'raw' messages and then remember to construct a JsonMessage from the raw message to access the new Body property, which is sort of just as much boilerplate as doing the deserialization themselves or calling the previous extension method.

After reminding myself how the publishing side works, I reckon a better approach is one that is symmetrical to that one - on that side I wrote a JsonMessagePublisher that wraps the raw RabbitPublisher, and so hides serialization from the caller entirely.

We could do the same on the consuming side with an abstract JsonMessageHandler of T that implements IMessageHandler, handles deserialization internally, and exposes a strongly-typed HandleAsync method for subclasses to override. That way the consuming service never touches raw messages or worries about deserialization at all - we can just call the JsonMessageHandler's HandleAsync which keeps things nice and clean.

Agree with all this. Gave me a few things to think about. Just put another version of it up there trying to adhere to this comment. Just making a local copy so I can test it with the print service. Let me know any thoughts

[lewisrenfrew]

This is better than the extensions approach from before, but we are still forcing consuming code to handle 'raw' messages and then remember to construct a JsonMessage from the raw message to access the new Body property, which is sort of just as much boilerplate as doing the deserialization themselves or calling the previous extension method.
After reminding myself how the publishing side works, I reckon a better approach is one that is symmetrical to that one - on that side I wrote a JsonMessagePublisher that wraps the raw RabbitPublisher, and so hides serialization from the caller entirely.
We could do the same on the consuming side with an abstract JsonMessageHandler of T that implements IMessageHandler, handles deserialization internally, and exposes a strongly-typed HandleAsync method for subclasses to override. That way the consuming service never touches raw messages or worries about deserialization at all - we can just call the JsonMessageHandler's HandleAsync which keeps things nice and clean.

Agree with all this. Gave me a few things to think about. Just put another version of it up there trying to adhere to this comment. Just making a local copy so I can test it with the print service. Let me know any thoughts

I already had to throw one together just to see if it would actually work:

#5

I like it