How to manage context objects in a multi tenant application?

Question

I'm building a Web API that interfaces SharePoint (an external web service). To get at connection to the external service I need to create instances of ClientContext with some kind of token.

For this I have created an interface called IClientContextFactory:

interface IClientContextFactory
{
    Create ClientContext(string siteUrl)
}

I have created an implementation HttpClientContextFactory that creates objects using the claims from the current HttpRequest that is injected into the factory. Based on the claims I know what tenant the ClientContext applies to.

This works well from the web api but what about my supporting console applications that doesn't have a user context? I have to send the tenant id with every message to these which in turn means that the IClientContextFactory interface doesn't work. For this I created IAppClientContextFactory:

interface IAppClientContextFactory
{
   Create(Guid tenantId, string siteUrl);
}

This feel awkward because now any implementation that depends on IClientContextFactory is useless in the console applications since I cant implement it without a user context.

I could add Create(Guid tenantId, string siteUrl) to IClientContextFactory but this would violate Liskov's since Create(string siteUrl) would throw a NotImplementedException in the console applications.

Is there a better way to do this? Am I taking the wrong approach to this? Am I even doing it correctly and shouldn't worry at all? It is difficult for new developers in particular to have to figure out what dependencies must be registered in the IoC container for their particularly application.

Answer 1

As I see, your problem is, that you try introduce web service's implementation details (Context) as abstraction.

"Leak abstraction" the name for this problem.

Consumers of web service doesn't need to know about how you send message. Consumers need only provide required data(arguments) and get result as return value.

public interface IWebService
{
    ResultType GetData(string credentials);
}

Then for web application and for console application you can implement them in different way.

Or even use same implementation, but way how you get required arguments will be different in web and console application

Answer 2

The best approach would be to have a pluggable identity provider which will vary based on the type of application that you are going to consume.

For example, Create an interface IUserContext which will have properties like user ID, tenant id etc. The web application with use something like WebUserContextProvider:IUserContext. Similarly, the services or jobs will have like JobUserContextProvider: IUserContext These implementation will be set via a DI like unity or autofac

HTH