EFCoreStoreDbContext vs MultiTenantIdentityDbContext

[NickBuckland]

Hi, sorry if I am missing the point again!!!

If I want to persist TenatInfo and Identity data in a SQL Db via EF Core, reading the docs it is not clear to me why I should derive the DbContext from EFCoreStoreDbContext. It seems (not tested yet) that deriving from MultiTenantIdentityDbContext will provide all the data isolation I need.

Is there a difference between the two classes?

Thanks Nick

[NickBuckland]

Ahhhh I think I have it now, correct me if I'm wrong.

The MultiTenantIdentityDbContext can be thought of an an extension to IdentityDbContext or should I say replaces it!?!

I now have a EFCoreStoreDbContext derived context to handle "Tenant context"
and a MultiTenantIdentityDbContext derived context to handle "Identity"

Just a note for others, as I am implementing a custom ApplicationUser rather than IdentityUser I needed to add the following to protected override void OnModelCreating(ModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
modelBuilder.Entity().IsMultiTenant();
}

[AndrewTriesToCode]

Sounds like you got it right. EFCoreStore is just a place where you tenants are listed out. Doesn't have any per-tenant data at all. Just a normal database used during tenant resolution (and you can use other store types if you prefer, don't have to use EFCoreStore).

MultiTenantIdentityDbContext is a subclass of IdentityDbContext so in a sense it is a replacement. It has baked in per-tenant data, but it's not always the best to use--for example not good if you want to have a many-to-many relationship between user and tenant.

[NickBuckland]

Great I'm on the right path thanks!
However I'm a little surprised, using MultiTenantIdentityDbContext I have managed to add a single UserName (or email) to many Tenants which I believe to be many-to-many (this is EXACTLY what I want). Are you saying that MultiTenantIdentityDbContext can't/shouldn't do this, are there some limitations?

[NickBuckland]

Hopefully I'm answering my own question.
I now see that there is an issue with UserManager and FIndById (that you mention in the docs)
So the problem is filtering a user by tenant?

[AndrewTriesToCode]

Hi, yeah if you look at the raw database you'll see that single user has a tenantId column. The way it works with a global filter query is that normal LINQ queries get the where condition for tenantId added automatically, but the FindByID on the dbcontext bypasses this and UserManager.FindById uses this so I can't do too much about it unless I replace UserManager altogether.

If you really want many-to-many then just use regular IdentityDbContext and add an entity for tenant (and relationships where applicable, user and maybe role). This dbcontext also can be used for EFCoreStore in this case which is nice.

The challenge you'll face here is when a user logs in which tenant should they get, assuming only one active at a time. Approaches I've used involve assigning the first tenant result or also specifying the default tenant as a user option. Then I've used session variables and the related strategy to resolve the desired tenant. A navigation dropdown which changes the session variable and reloads the page does the trick. Hope this helps!