Ok, but then auto-resolving dependencies in services won’t work.
ps. The .NET Core is also using a nested container approach
https://docs.microsoft.com/en-us/aspnet/core/api/microsoft.extensions.dependencyinjection.iservicescopefactory
Funq also has a CreateChildContainer method, but it’s not used in servicestack at the moment…
How does the current Funq container handle singleton registrations?
Not sure what you mean, it’s singleton by default and injects the same instance.
In the AppHost.Release every instance is diposed (if IDisposable), but maybe i’m missing something, still new to the codebase…
It doesn’t add singletons to the track disposables list.
ahh I missed this line
Adding a custom ContainerAdapter allows your services to resolve its dependencies from an alternative IOC, in this way they act like a dependency repository where the services are still registered in Funq but all their dependencies are resolved by the ContainerAdapter specified.
So you have to register the dependies in both Funq and the IContainerAdapter…
No, it’s saying Services (i.e classes inheriting ServiceStack’s Service) class is still registered in Funq, but all its dependencies are resolved through the Container Adapter.
It doesn’t affect where you want to register dependencies which you can choose to register in either Funq or your preferred IOC.
I’ve examined the code a bit more and have question
If you register an object in the container adapter (not in funq) with a singleton scope and it’s resolved by Funq, how does Funq know the scope of the resolved service (and/or nested resolved services)?
Funq can’t know the reuse scope in an external IOC.
But then it’s better to not use an external IOC/the adapter feature. Correct?
I’ve never needed anything more than Funq but it wont matter if your singletons don’t implement IDispose also your ContainerAdapter can implement IRelease to have the external IOC handle releasing their own dependencies.
One thing that i’m missing in Funq is the ResolveAll() method (and register more types implementing the same interface)
Another issue with funq is reported in this thread
RequestScope shouldn’t be used outside the HTTP worker request thread, e.g in background threads.
Correct, but what is the alternative in Funq for RequestScope?
Not Request, so Reuse None or Singleton. Reuse None when it’s not Threadsafe.
Yes, but none/transient scope is not the scope i need for for example IDbConnection.
May I suggest to make the AppHost.Container pluggable so we can optionally replace the container with a different implementation?
You definitely want to use ReuseNone for pooled resources like IDbConnection to minimize the amount of time an open connection is kept unavailable from the pool.
The Container adapter is how to integrate an external IOC, there’s no plan for anything different. In .NET Core you can use their IOC to register Service dependencies.
Using two IOC containers is of course not an option and if you use the container adapter Funq doesn’t know the scope of the resolved services…
using funq only seems the only option, use the childcontainer for context without a request,
but then I miss my ResolveAll feature.