C# Service scope concern

Question

I am using dependency injection on a project to inject services using Unity dependency injection

private async Task<T> GetResult<T>(HttpResponseMessage response)
    {
        if (typeof(T) == typeof(byte[]))
        {
            return await(response.Content.ReadAsByteArrayAsync() as Task<T>);
        }
        else if (typeof(T) == typeof(System.IO.Stream))
        {
            return await(response.Content.ReadAsStreamAsync() as Task<T>);
        }
        else if (typeof(T) == typeof(string))
        {
            return await(response.Content.ReadAsStringAsync() as Task<T>);
        }
        else
        {
            return jsonService.Deserialize<T>(await response.Content.ReadAsStringAsync());
        }
    }

I am injecting the json service in the constructor.

IJsonService jsonService;

    public HttpClientService(IJsonService _jsonService)
    {
        jsonService = _jsonService;
    }

The question that i have is as follows. Is the JSON deserialization a concern of HTTPService or should I remove the following from the http service? (if the de-serialization fails it returns null)

return jsonService.Deserialize<T>(await response.Content.ReadAsStringAsync());

The Json Service is as follows

public class JsonService : IJsonService
{
    public T Deserialize<T>(string input)
    {
        return JsonConvert.DeserializeObject<T>(input);
    }

    public string Serialize<T>(T input)
    {
        return JsonConvert.SerializeObject(input);
    }
}

Answer 1

This is somewhat subjective, but I personally feel that it depends entirely on whether or not all HttpClientService requests will send/receive JSON. Let me explain. Using HttpClientService work independently of JsonService has the advantage of flexibility. This means you can easily handle JSON requests as easily as any other. It also adds an additional step to process JSON requests as you would obviously need to serialize/deserialize accordingly, which of course has the disadvantage of additional complexity in your program design.

If all your requests are going to be JSON requests, then it is no longer "optional" to pass through JsonService. So the advantage of flexibility doesn't apply, and so you'd only get the disadvantage of complexity should you keep them separate.

Based on your code, it would appear you're already forcing the return of requests to Task<T>, meaning you're already taking it upon yourself to parse and interpret the result. Therefore I would recommend you either completely integrate JsonService into HttpClientService or rewrite HttpClientService to take a less aggressive role in handling parsing of messages should this not meet your requirements.

Answer 2

I'm not sure if you are asking whether you'll need a json-service at all or whether you should use dependency incjection for it... I assume the latter as the former should be actually clear. Otheriwse it would mean you don't know what you are doing.

It is not possible to tell you whether you should use use dependency injection in this case or not but you can answer a few questions to have a reason for either choice: Why do we use dependency injection in the first place? Mostly to be able to exchange a service in future or to mock it for testing. How likely is that in your case? Will you be ever replacing it with something else? Does it make sense? Is it at all possible?

Another reason for dependency injection is that you have only one place where you configure a service. Do you use custom settings for the (de)serializer? Is there more then one module that will use this service? Do you want to use the same settings everywhere or do you want them be be easily adjustable?

If most of your answers is yes then I'd use an injectable service otherwise it might not be necessasry.