Dependency Injection for singelton class with properties

For the dependency injection you need an interface which gets initialized, so your MyCustomContext class needs to implement a new interface called IMyCustomContext. The interface can look like following:

public interface IMyCustomContext
{
    HttpContext Context { get; }
    User LoggedInUser { get; }
    Collection<SiteWideSettings> SiteWideSettings { get; }
}

public class MyCustomContext : IMyCustomContext
{
    public HttpContext Context
    {
        get { return HttpContext.Current; }
    }


    public User LoggedInUser
    {
        get
        {
            // Logic to return current user based on logged in user
        }
    }

    public Collection<SiteWideSettings> SiteWideSettings
    {
        get
        {
            // Logic to return SiteWideSettings
        }
    }
}

In the Startup.cs there is a method called ConfigureServices, there you can add the following for the dependency injection:

container.RegisterType<IMyCustomContext, MyCustomContext>(
    TypeLifetime.Singleton);

It's worth pointing out that Singleton has dual meaning here:

• The Singleton Design Pattern ensures an object is only instantiated once. Its implementation isn't ideal though, as it relies on ambient state.
• The Singleton Lifetime is used by IOC frameworks, where it ensures the same reference of an object is used every time.

In short, the Singleton Lifetime effectively removes the need to implement the Design Pattern, because the IOC framework ensures the backing concept for you.

Meaning, if we register our dependency with the Singleton Lifetime.

container.RegisterType<ICustomContext, MyCustomContext>(TypeLifetime.Singleton);

We can remove the code for the Singleton Pattern, as the IOC container will take over the responsibility of guarding the single instance/reference.

public class MyCustomContext : ICustomContext
{
    public HttpContext Context => HttpContext.Current;

    // Logic to return current user based on logged in user
    public User LoggedInUser => ...
    
    // Logic to return SiteWideSettings
    public Collection<SiteWideSettings> SiteWideSettings => ...
}

I've also added the ICustomContext interface with the member we're interested in.

public interface ICustomContext
{
    HttpContext Context { get; }
    User LoggedInUser { get; }
    Collection<SiteWideSettings> SiteWideSettings { get; }
}

Can you share how to moq properties of that class?

That's right, we just moved the problem one level, didn't we? If you need to extract an interface, you usually need to do this in a recursive manner.

This also means HttpContext is not a good candidate for an interface member, which makes sense when you think about it. From a unit test's point of view, we're not interested in verifying ASP.NET's inner workings. Instead, we want to check our own code, and only that portion, with no dependencies on foreign libraries. To do so, you should only copy the HttpContext members you need on to your interface and remove the dependency on HttpContext (which is notoriously hard to abstract).

For example:

public interface ICustomContext
{
    IPrincipal User { get; }
    User LoggedInUser { get; }
    Collection<SiteWideSettings> SiteWideSettings { get; }
}

This will require some refactoring / remodeling as the number of properties grows.

For simple DTO's you can even choose not to abstract / interface them, as long as your able to easily create fakes for unit testing. Also remember it only makes sense to introduce an interface if there are going to be multiple implementations.

One more thing about Dependency Inversion, and how IOC frameworks work, you usually let the dependencies bubble up. The recommended approach is through constructor injection, as illustrated in the following ICustomContext implementation for unit tests.

public class TestCustomContext : ICustomContext
{
    public MyCustomContext(IPrincipal user, User loggedInUser, Collection<SiteWideSettings> siteWideSettings)
    {
        User = user;
        LoggedInUser = loggedInUser;
        SiteWideSettings = siteWideSettings;
    }

    IPrincipal User { get; }
    User LoggedInUser { get; }
    Collection<SiteWideSettings> SiteWideSettings { get; }
}

I have one more question, do the properties like LoggedInUser, SiteWideSettings and Context of MyCustomContext class should be written as properties or they should be converted to methods for dependency injection?

You can have both. If the state was injected through constructor injection, you might as well expose it as a property. If the implementing class implements behavior to create / transform the state, you might want to expose the behavior as a method. It all depends on the actual case, there is no golden bullet here. Just remember that in OO design, interfaces are used to model behaviors, with their scope kept as small as possible.

UPDATE

Those properties are not getting filled via constructor. All of these properties "IPrincipal User { get; } User LoggedInUser { get; } Collection SiteWideSettings { get; }" have the body in their getter, they get the data from cache first and if not found then it calls the service to get the data from db for those properties (all that is written in in the get of those properties). Should I keep them as properties only or make them methods?

Let me split up your question.

Should I keep them as properties only or make them methods?

From a technical point of view, it doesn't really matter. Properties, or automated properties (like the ones you're using), are just syntactic sugar over full blown methods. Meaning, they all get compiled into equivalent CIL instructions.

That leaves only the human factor. The readability and maintainability of your code. The agreed upon coding style and practices. That's not something I can answer for you. Personally, I prefer methods for handling these kind of code flows.

they get the data from cache first and if not found then it calls the service to get the data from db for those properties (all that is written in in the get of those properties).

Sounds like this class is more of a service provider than an actual model class in your domain. As there's also I/O involved, I'd definitely recommend switching to asynchronous methods on your interface. The explicit (Task based) signature says a lot to fellow developers reading your code.

The part where I talked about the dependencies bubbling up plays an important role here. The cache and repository are both dependencies of MyCustomContext. IOC and its inherent Dependency Inversion Principle rely on the explicit declaration of dependencies, as shown in the following sample. Note the implementation of GetLoggedInUser() is not what matters here, rather the way the dependencies are set through the constructor. All these dependencies need to be registered with your IOC container first, for it to be able to resolve ICustomContext.

public class MyCustomContext : ICustomContext
{
    private readonly IUsersCache _usersCache;
    private readonly IUsersRepo _usersRepo;

    public MyCustomContext(IUsersCache usersCache, IUsersRepo usersRepo, IPrincipal principal)
    {
        _usersCache = usersCache;
        _usersRepo = usersRepo;
        Principal = principal;
    }

    public IPrincipal Principal { get; }

    public async Task<LoggedInUser> GetLoggedInUser()
    {
        var userId = await GetUserId(Principal);
        var user = _usersCache.GetById(userId);
        if (user == null)
        {
            user = _usersRepo.GetById(userId);
            _usersCache.Add(user);
        }

        return user;
    }

    ...
}

Those properties are not getting filled via constructor. All of these properties "IPrincipal User { get; } User LoggedInUser { get; } Collection SiteWideSettings { get; }" have the body in their getter

I don't think that's true for IPrincipal as it, together with HttpContext, is instantiated by ASP.NET behind the scenes. All you need to do is tell the IOC container how to resolve the current IPrincipal and let it work its magic.

Likewise, all classes that depend on ICustomContext should have it injected by the IOC container.

public class MyService : IMyService
{
    private readonly ICustomContext _customContext;

    public MyService(ICustomContext customContext)
    {
        _customContext = customContext;
    }

    public async Task DoWork()
    {
        var currentPrincipal = _customContext.Principal;
        var loggedInUser = await _customContext.GetLoggedInUser();
        ...
    }
}

An important part here is again unit testing. If you design your classes like this, you can easily create fakes for testing. And even if there wasn't any testing involved, which I wouldn't recommend, the ability to decouple classes like this is a good indication of a well designed code base.