Feat/serializer context decoupling

[maurei]

Overview decoupling PR

This is an intermediate PR intended to provide insight into the structural decisions made so far. Please limit feedback to those elements. Commenting, variable naming and spacing consistency will be further improved along the way.

This PR contains rework of three main elements:

• Deserializer
• Serializer
• Breaking up of RequestManager into more separated isolated services [WIP]
• Breaking up ResourceGraph [WIP]

Serializers and Deserializers

see wiki here.

RequestManager

The RequestManager was becoming too big and it contained too many responsibilities. I have introduced the following approach.
The request manager is split up into services in one of two categories:

• URL query param services: stuff related to anything behind the ? in URL, like inclusions, filters, etc.
• request scope meta services: remaining meta data associated to scope of one request, like the main resource of the request (eg. Article when route like /articles**).

URL query param services

Each URL query operator has been moved to its own dedicated service. This is to prevent that if a service needs only a small subset (eg IncludedRelationshipBuilder needs only the inclusion chains), it does not exposed to all the other query parameters too.

• IPageQueryService the former page manager
• IFieldQueryService to access sparse field selections
• IIncludedQueryService to access inclusion chains
• IAttributeBehaviourQueryService to encapsulate the feature described here
• Others are yet to be implemented: FilterQueryService, SortQueryService. I might be missing more.

Each service will also contain "business logic" related to that particular service. For example IIncludedQueryService

• knows how to convert a chain ("articles.author.favorite-food") into corresponding RelationshipAttributes
• throws errors when a non-existing relationship is targeted

Request scope meta services

Remaining metadata associated to a particular request. Also separated into multiple small services to prevent unnecessary exposure of data.

• IUpdatedFields to keep track of which fields of a resource (AttrAttributes and RelationshipAttributes) are targeted in the scope of a request.
• ICurrentRequest to access metadata that is not (yet) isolated to its own service. Like the main resource of a request.

Todo:

see the App vs. Request vs. Operations section in #253. Currently the RequestManager had both request-level and operational-level state information (updated attributes/relationships vs main request resource).
This particular example has been separated but we need to further categorize the above services such that it is compatible with this distinction.

We will currently not support bulk operations (dedicated issue + PR coming soon) for v4, but in order to re-support it in the future it is important to properly distinguish between operation-scoped services and request-scoped services (eg. IUpdatedFields is operation-level, ICurrentRequest request-level). All requests will then, for now, be associated to one operation, but can be associated with more.

ResourceGraph

Throughout JADNC, the resource graph is used for two purposed

• getting ContextEntity given a exposed resource string, resource type, controller name
• resolving relationships which require a lot of information from the graph, eg many-to-many relationships.

Because of these two pretty deviating responsibilities, I have introduced

• IContextEntityProvider just to get a ContextEntity (various overloads)
• still need to put the rest of resource graph behind a new interface, something like IRelationshipResolver, which can probably be merged with the already existing IInverseRelationshipResolver which was introduced in ResourceHooks.

Todo

Few things are left to be done in the domain of serialization:

• Support camelCase configuration as member names and resource names. Need to think about how to make this configurable in such a way that it Allow for multiple naming conventions (camelCase vs kebab-case) #555 is addressed.
• Sparse field selection on included members in IncludedRelationshipBuilder.

Things left to be done in general

• Wiring back up parsing of URL query parameters in QueryParser
• Applying these queries in the data layer: JsonaApiContext is still in there, we need to create something like a QueryProcessorFactory service that instantiates eg SortQuerys or FilterQuerys using DI, and use that in the places were manual instantiation is being performed right now (see the DefaultEntityRepository class).
• Removing the operations experimental feature. We might put it back later but for now it would delay v4 release by too much time. Also the current implementation deviates a lot from the extension that might be included in the v1.1 specs
• Removing the EntityResource separation example and related code. See [RFC] Deprecate support for Resource Entity Separation  #553