4

I am building a web api with asp.net and i am using the UnityContainer for handling dependencies.

For example, my auth controller can depends on the auth service:

class AuthController : ApiController {

    private IAuthService authService;

    public AuthController (IAuthService AuthService) {
        this.authService = AuthService;
    }

    ...
}

And the implementation of my auth service can depend on my user repository:

class AuthController : IAuthService {

    private IUserRepository userRepository;

    public AuthService (IUserRepository UserRepository) {
        this.userRepository = UserRepository;
    }

    ...
}

Now, i know that unity has two ways of handling dependencies, it can create a new instance of the dependency every time it is required, or it can save the instance of the dependency as a singleton and inject that same singleton every time the dependency is required.

By default, unity does it the first way (creates a new instance every time).

My question is: should i keep it that way, or should i tell unity to keep my services and repositories as singletons?

This question really came to my mind when my user repository depended on some other dependency, and that dependency depended on the user repository. When i tried to run the web api, it throw a stack over flow exception and i figured that it did this because it had to create a new instance of the user repository and the other repository every time.

Thank you, Arik

areller
  • 3,476
  • 5
  • 25
  • 41
  • 1
    Can your repository function as a singleton? Without knowing how your repository is implemented it's hard to say. I would resolve the circular dependency problem before trying to make it a singleton. – Nick Aug 14 '15 at 19:16
  • You want a new instance per request. – Jasen Aug 14 '15 at 19:18
  • ya, fix your circular dependency first. only reason I would use a singleton is to keep track of states that I don't want to lose (ex: IsAuthenticated). – vidalsasoon Aug 14 '15 at 19:58

2 Answers2

2

Creating a new set of instances per HttpRequest is likely what you want. This prevents you from some unintended side effects messing up some logic if something gets cached within an instance. If you scope it at the HttpRequest level, and your dependency chain depends on a certain repository 4 different times, they'll all share the same instance of that repository.

Here is how you can do that in Unity: MVC, EF - DataContext singleton instance Per-Web-Request in Unity

Community
  • 1
  • 1
viggity
  • 14,639
  • 7
  • 79
  • 91
1

You should not use singleton for dbcontext. You can use per httprequest lifetime or per resolve lifetime. To add per request lifetime you can use nuget package Unity.WebAPI

Kirill Bestemyanov
  • 11,721
  • 2
  • 20
  • 37
  • But a `DbContext` should not be injected as dependency into a constructor. The object graphs you resolve should purely consist of components (classes that contain the application's behavior) and they should typically be stateless. A `DbContext` is neither: it contains no application behavior and is merely a big request-specific state bag. Instead of injecting the DbContext, you should pass it through the object graph like you do with all other state. There are multiple ways to do this, such as using an `IDbContextProvider` abstraction with a `CurrentContext` property or use `IUnitOfWork`. – Steven Aug 15 '15 at 10:22
  • Just inject factory Func. Unity can do this when you register DbContext. – Kirill Bestemyanov Aug 16 '15 at 11:03
  • Func is fine of course; that will ensure it's not part of the object graph. – Steven Aug 16 '15 at 11:12