json-ld.net icon indicating copy to clipboard operation
json-ld.net copied to clipboard

Support dependency-injection

Open goofballLogic opened this issue 3 years ago • 3 comments

The normal usage pattern for the library is to use the static JsonLdProcessor class. This works well for the stateless, static algorithms which make up the JSON-LD standard. However, it requires a consumer to create an injectable facade class in order to inject the APIs into consumers. e.g.

interface IJsonLdProcess {
    JObject Compact(JToken input, JToken context, JsonLdOptions opts);
}

class JsonLdProcess {
    JObject Compact(JToken input, JToken context, JsonLdOptions opts) {
        return JsonLdProcessor.Compact(input, context, opts);
    }
}

public class Consumer {

    private readonly JToken _context;
    private readonly IJsonLdProcess _jsonLdProcess;

    public Consumer(IJsonLdProcess jsonLdProcess, JToken context) {
        _jsonLdProcess = jsonLdProcess;
        _context = context;
    }

    public JObject Execute(JObject input) =>
        _jsonLdProcess.Compact(input, _context);
    }
}

Can we provide the functionality exposed by JsonLdProcessor as a non-static implementation of an interface which can be mocked for purposes of unit testing / decoration.

goofballLogic avatar Jul 05 '20 11:07 goofballLogic

interface IJsonLdProcess {
    JObject Compact(JToken input, JToken context, JsonLdOptions opts);
}

This interface would require a dependency on Json.NET, so I would prefer a signature that only dealt with objects we defined in our own Core. Something like this:

interface ILinkedDataProcessor
{
    LinkedDataObject Compact(LinkedDataObject input, LinkedDataContext context, LinkedDataOptions options);
}

This would make the Core to be dependency-free and allow Json.NET, System.Text.Json, Turtle, and possibly other serializations as ancillary projects to the Core.

asbjornu avatar Jul 05 '20 12:07 asbjornu

Agreed. I was not proposing an exact interface here. I also think that we should allow that #66 and #65 might be implemented in either order since we are evolving the codebase

goofballLogic avatar Jul 05 '20 14:07 goofballLogic

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Oct 03 '20 15:10 stale[bot]