JsonApiContext should be split into multiple classes for easy testability

[wisepotato]

And we are mostly concerned with making sure that the deserializer has no need for the current HttpContext so that we can stop with E2E testing trivial stuff.

• JsonApiContext is scoped

With these notes we want to see the lifecycle of the JsonApiContext

Where does Middleware touch JsonApiContext

These fields are being set by means of JsonApiContext :

• JsonApiContext.BeginOperation()
  • IncludedRelationships = new List<string>(); - Is populated in ApplyContext(controller)
  • AttributesToUpdate = new Dictionary<AttrAttribute, object>(); - Populated in deserializer
  • RelationshipsToUpdate = new Dictionary<RelationshipAttribute, object>(); - populated in deserializer
  • HasManyRelationshipPointers = new HasManyRelationshipPointers(); - Populated in deserializer
  • HasOneRelationshipPointers = new HasOneRelationshipPointers(); - populated in deserializer

Controller

jsonApiContext.applyContext(this ) this = controller
QuerySet = _queryParser.Parse(context.Request.Query);
BasePath = new LinkBuilder(this).GetBasePath(context, _controllerContext.RequestEntity.EntityName);
PageManager = GetPageManager();
IsRelationshipPath = PathIsRelationship(context.Request.Path.Value);
so

• Initilization of JsonApiContext field happens in the deserializer (Middleware) and controller
• afterwards the fields of JsonApiContext are used readonly (I think

Things that need to be taken out of the deserializer

• Its convenient that when you are going through it you register the JsonApiContext because we need it later on in the repository/service layer. But we don't need it for `JsonApiClient in the repo/service layer
  • How to solve this .. and stay flexible?
• Things that need to be parsed in the controller

  • In stead of using the JsonApiContext itself we should use a relevant service for this, maybe even multiple, and inject them when needed

    JsonApiContext wordt dan eigenlijk een JsonApiContextInitializer, in de zin van dat het niet de context zelf meer is maar alleen de context populate in de set van context services.

Scoped

• URL query parameters -> QueryParamFetcher
• Body -> BodyInterpreter
• Hooks -> HookExecutor
• ResourceDefinition

Singleton

• Options -> OptionsFetcher
• Generic processor factory GenericProcessorFactory
• LoggerFactory
• IResourceMapper - MapIn + MapOut
• MetaBuilder - Inject when needed

[maurei]

resolved in #558