Revisit IOpenApiContext design
idg10 opened this issue · 3 comments
As discussed in #20 (comment) the current design of IOpenApiContext looks a bit off, and has resulted in some slightly curious features in the code. That discussion is in an issue that is only tangentially related, so I've created this issue to track the IOpenApiContext-specific thinking.
We're considering removing the specialized members that handle tenancy and user identity, and replacing them with a more generic mechanism similar to the 'feature collection' system that ASP.NET Core uses to solve a similar problem.
I agree that this is much more closely aligned with the original concept (if not the original "design")
I am working on a "removing the IOpenApiContext entirely" strategy. This was fairly straightforward. I am now introducing a per-request container scope, and moving the IOpenService to Transients resolved from that child container. We can then register per-request context from layered-in services like Auth and Tenancy in their own types, which can be injected into the services that care.
We can review this model and see whether it better meets our needs.
OK - having dug into that route and discussed the outcome... I have a new proposal. We return to IOpenApiContext as the pattern, modelled on the HttpContext (with its FeatureCollection) and also add the IOpenApiContextAccessor analog of IHttpContextAccessor with its AsyncLocal implementation.
This avoids the Scoped DI (that can be registered as a singleton) and uses the AsyncLocal to manage scope.
Thoughts? @idg10 @jongeorge1