json-ld.net
json-ld.net copied to clipboard
Support dependency-injection
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.
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.
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
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.