|
NihilCredo posted:i also think this is usually the cleanest option. no query filters, just a separate connection string per tenant. another thing to be wary of with one-db-per-tenant (or indeed anything that varies the db connection string per tenant) is that ef core support is sketchy, iirc. you'll need to figure that bit out on your own obviously not a concern if you're not using ef
|
# ? May 1, 2024 00:31 |
|
|
# ? May 4, 2024 14:33 |
|
If you inject your ITenantProvider with your OnConfiguring method for entity framework, you can use a scoped database service no problem. I have used this approach several times, and it works well. I can probably get you some sample code tomorrow if you like.
|
# ? May 1, 2024 01:12 |
|
ChocolatePancake posted:If you inject your ITenantProvider with your OnConfiguring method for entity framework, you can use a scoped database service no problem. I have used this approach several times, and it works well. I can probably get you some sample code tomorrow if you like. This would be appreciated! I've also been looking at Finbuckle Multitenant tonight which seems to be a potential solution as well.
|
# ? May 1, 2024 02:13 |
|
I've not used Finbuckle before, but it looks intriguing. This is what I do:code:
This is with SqlServer, but should work the same with Postgres. Hope that helps!
|
# ? May 1, 2024 02:36 |
|
It'd be different for everyone, but what criteria is commonly used to set the TenantID in MyTenantIdentifier to "TenantA" or "TenantB" in an ASP.NET Core project (the currently logged in User? the subdomain?), and where is a reasonable place to store that information?
|
# ? May 1, 2024 04:17 |
|
We like to use subdomains, storing the mapping in a config file, makes it easier for us, but there's lots of ways to skin that cat.
|
# ? May 1, 2024 04:22 |
|
You don't even need to bury it in the DbContext OnConfiguring like that, you can do it right in your application's startup. The AddDbContext extension method for IServiceCollection has an overload to provide a function that takes IServiceProvider as one of its arguments, so you can get your tenant-providing service there and keep all your configuration during service registration where it belongs.ChocolatePancake posted:We like to use subdomains, storing the mapping in a config file, makes it easier for us, but there's lots of ways to skin that cat. We do that for our IDP (mapping to tenant by hostname); then for all our application services we map based off the issuer of the passed OAuth access token. But there are still some things that are difficult to make per-tenant; so we structure our web applications to have the initial WebApplication host built, and all that host does is look at the supplied bearer token to identify the issuer, then passes the request off to a separate tenant-specific host instance (one per tenant -- created on demand when the first request for a particular tenant hits the process), which then handles it exactly like it would if it were a single tenant application because it basically *is* just running lots of separate single tenant applications all in one process. You also don't get boned if you ever need to use a library that assumes a single tenant application; and you never ever accidentally do things like mix up memory caches cross-tenant or any of the other pitfalls you might fall for if you're not hypervigilant about making sure you never accidentally assume a single tenant. biznatchio fucked around with this message at 04:37 on May 1, 2024 |
# ? May 1, 2024 04:34 |
|
epswing posted:It'd be different for everyone, but what criteria is commonly used to set the TenantID in MyTenantIdentifier to "TenantA" or "TenantB" in an ASP.NET Core project (the currently logged in User? the subdomain?), and where is a reasonable place to store that information? Our IDP just adds the tenant ID to the user's claims.
|
# ? May 1, 2024 20:51 |
|
|
# ? May 4, 2024 14:33 |
|
susan b buffering posted:Our IDP just adds the tenant ID to the user's claims. I really like this method.
|
# ? May 1, 2024 23:31 |