Skip to content

Notes

Jump to bottom
Darrell edited this page May 3, 2019 · 2 revisions

Work In Progress

When request comes in:

  • phase 1: Tenant identification (middleware) identifies the tenant. Can use different / custom implementations to identify the tenant - out of the box, it will be easy to configure URL based, or cookie based identification.

  • phase 2: tenant container (middleware)

    • Retrieves the container for the current tenant. If the tenant container doesn't yet exist (like on first request to tenant) it will execute a delegate to configure the tenants container (i.e register services). The current tenant is exposed to this configuration delegate. The configured tenants container is stored in the tenants TenantContext which is a dictionary cached on the server for the lifetime of that tenant within the application. In future dotnettency will provide a way to invalidate TenantContext such that the next request to a tenant will cause the container to be re-built, along with anything else that is cached in TenantContext.

    • When using Tenant Containers, it is important that this container is set as the "active" container, before the request is allowed to flow onwards through the middleware pipeline. Dotnettency container middleware will ensure that this happens. For ASP.NET Core hosting environments this means:

      1. HttpContext.RequestServices will be swapped for a new scoped container, created from the current tenants container (IServiceProvider). This scoped container is disposed of at the end of the request.
      2. A custom IHostingEnvironment will be registered in the tenant's container automatically when the container is configured. This is done to override the default one, with ApplicationServices property set to the tenant container. This is necessary because some services used in asp.net core MVC, end up resolving IHostingEnvironment and leveraging IHostingEnvironment.ApplicationServices directly to resolve other services. This means when configuring MVC during a request scoped to the current tenant, these configuration methods can break out of the scope of the current tenants services, and work at the application level services. Dottnetency registers this custom IHostingEnvironment implementation in the tenants container, so that as the request continues through the pipeline, any attempt to resolve IHostingEnvironment and use its ApplicationServices will instead resolve to the current tenants default container.

OWIN: stores container in tenant context, and sets key in OWIN environment?

-- tenant pipeline (middleware, builds tenants pipeline and stores in tenant context onfirst requests. then flows request through it..

              ASP.NET Core - when building pipeline, a configuration delegate is called, IServiceProvider is exposed
                 and is set to either the application level IServiceProvider, or the current tenants if Tenant Container is established.

                 However, some asp.net core configuration methods are hard coded to use IHostingEnvironment.ApplicationServices -
                 therefore we register a custom IHostingEnvironment with ApplicationServices set to the tenant container IServiceProvider (if tenant container is used).

              OWIN - when building pipeline, a configuration delegate is exposed. The IServiceProvider for tenant container (or application level) is via OwinEnvironment key.

(could just use tenant idetification) and (tenant pipeline) without using tenant container..

when tenant pipeline is configued, if tenant container is established, then it will be used for di. Otherwise the default applicatiojn level container is used.

Clone this wiki locally