Implemented Tenant Identification Service to dynamically resolve database connection strings based on 'X-Client-ID' header

[rajibmahata]

Implemented Tenant Identification Service to dynamically resolve database connection strings based on 'X-Client-ID' header. Removed middleware dependency for connection resolution to ensure accurate handling during request lifecycle. Added support for dynamic DbContext creation for multi-tenant architecture

[rajibmahata]

@microsoft-github-policy-service agree

[rajibmahata]

How It Works

Tenant Identification Service:
We created a service that checks the X-Client-ID header in the HTTP request. If a valid client ID (e.g., ClientA or ClientB) is found, it retrieves the corresponding connection string from the application configuration. If the client ID is missing or invalid, the request is rejected.

DbContext Factory:
Instead of configuring the database context (DbContext) during application startup, we now dynamically create it at runtime. A custom factory ensures that the correct connection string, based on the identified client, is used to configure the DbContext.

Request Lifecycle:
Each request now goes through the Tenant Identification Service, which dynamically resolves the connection string. The service is scoped to the request lifecycle, ensuring each client’s request is handled with its specific configuration.

Example Use Case:
When a request is made with X-Client-ID: ClientA, the service retrieves ClientA’s connection string and passes it to the DbContext. This can be changed dynamically by altering the header value in the request. Similarly, requests with X-Client-ID: ClientB will use ClientB’s database.