Understanding VContainer

[SimonNordon4]

I was trying to add some functionality to VContainer.

Specifically something similar to Zenject's .WhenInjectedInto() attribute. This creates a conditional binding.

Digging through the code, it looks like the Registry is a Dictionary with the Binding Type as the Key.
This mean a type can only ever be bound once in the registry, meaning you couldn't do.

builder.Register<T>.AS<Interface>.WhenInjectedInto<R>();
builder.Register<T>.AS<Interface>();

ideally these would be two separate bindings, and I guess the WhenInjectedInto would need to resolve after as well.
I have a feeling if the dictionary key was changed from (Type) to (Type, ConditionalArgs) then you would be able to do this.

Then it would do something like:

• Resolve all Type, ConditionalArgs where the Args are null.
• Resolve all Type, ConditionalArgs and use the Conditional Args in the Injector method.

So maybe it's possible to extend this to conditionals in general where you pass in an action:

builder.Register<T>.As<Interface>.When(c => c is typeof(R))

[SimonNordon4]

Okay I just had to read the docs more carefully.

Inversing builder.Register.As.WhenInjectedInto just becomes Register().WithParamater(T);

[furkasf]

Hey Simon, I recently start to use Vcontainer do you know how to resolve registered objects at runtime with an API call from the lifetime scope instead of instantiating that class and its dependencies again?

var serviceA = new SerivceA(); var serviceB = new SerivceA(); var entity = new Entity(serviceA, serviceB);

Injecting dependencies every time we instantiate an object feels like it breaks the point of IoC . Can we resolve the dependency of a registered class at runtime with a direct call to the resolver?

ex
var entity = LifetimeScope.Resolve<Entity >();

[SimonNordon4]

If I understand your question correctly then a factory would usually be used for this.

Generally you're not supposed to resolve objects outside of the lifetimescope, with factories being the one exception.

https://vcontainer.hadashikick.jp/registering/register-factory

So in your case you could have a class

builder.Register<Entity>(LifetimeScope.Transient);
builder.RegisterFactory<Entity>(container => { return container.Resolve<Entity>();}, LifetimeScope.Singleton);

Then in your class you would inject a Func.

[Inject]private Func<Entity> entityFactory:

Void Start()
{
   var newEntity = entityFactory();
}

There are many ways to configure a factory and would usually recommend creating an explicit factory class unlike the lambda expression I used here.

[furkasf]

Thanks for the answer. Yes, I want to try resolving objects outside of the lifetime scope. Factories seem to work well. Do you know any demo projects that demonstrate the use of VContainer to better understand the framework?

[SimonNordon4]

Unfortunately there aren't many.

Your best bet is to check out the examples in the Extenject GitHub repo, which is very similar to VContainer.

Im not sure it's a good idea to use VContainer as the only framework to build your game.

I've been trying for 4 months without success, too many things that aren't friendly with Unity, like pooling gameobjects and other 3rd party plugins.

Instead I've chosen a hybrid between VContainer, UniRx and monobehaviours in an MVC pattern.

[furkasf]

Thanks for the advice. I don't really try to make a brand new game framework based solely on VContainer. I just want to integrate IoC into my existing game framework. For doing this, I can either write my own service locator or use one of the existing DI frameworks. So I decided to use Vcontainer which is look simple enough(less complex) to integrate with my framework compared to other DI frameworks( Zenject ).

[SimonNordon4]

That sounds like a good use of VContainer, anytime you're tempted to create a singleton, registry or service locator, is a good time to use IoC.