So finally going down this path. Obviously, a lot of tables are now going to have a TenantID column. But I don't want to be writing TenantID everywhere, I want it to happen automatically. I can't think of any reason why any given thread would be dealing with multiple tenants at once.

I was thinking that I would have to radically update the templates to be smart to remove TenandID from the parameter lists, for example constructors, and then inside, get the TenantID from a thread scope variable on some other utility class I write. Whenever the win client app starts or the http request comes in, this TenantID would be set centrally.

Likewise, when doing searches, if the GetMulti call detects that the entity in question has a TenantID field, it would basically create a new Predicate that wraps the old predicate and adds an "AND TenantID=xxx" taken also from that thread scope variable.

Am I crazy? Should I just write TenantID everywhere and pray that developers will make sure to always add this also? I have to say, I do like the idea of it being automated away behind the scenes.

For the separate admin tool that manages the tenants, I would just use a normal library there with the standard templates.

Hi happyfirst,

This is not really an LLBLGen question, that's why the lack of answers. But whatever decision you make LLBLGen can handle it. Personally I like the DAL the it is, so I wouldn't change the templates. IMHO the TenantId is something you should carry on the context of the thread application, be it a WebApp, a WebService, a Console, a service, etc.

I understand, I was just curious to see if anybody else had done anything with custom templates for a multi-tenant design.

I have no doubt LLBL can handle it. But can our developers? Do they have the discipline? I don't think they do.

It's one thing to make TenantID be a required field and that would affect new records and loading via constructor. There it's in one's face.

But for searching, they'd "almost" always need to go and make sure to add TenantID. And when getting into complex queries where TenantID needs to be at the complete outside and guaranteed to be part of the outer most AND, it could involve more extra code to make sure the parenthesis are correct.

I may take a crack at trying to make some custom multi-tenant templates do make multi-tenant db as bulletproof as possible.

You may try to derive from the DataAccessAdapter and override the needed methods like: CreateSelectDQ() where you add the default predicate.

Also you can use Validator classes to inject the value of the tenant Id in each entity getting saved. ( hint: ValidateEntityBeforeSave() ).