How can I inject dependencies into nested objects?

[JesseTG]

I'm trying to use VContainer to inject dependencies into nested objects that are not derived from MonoBehaviour. Here's what I mean.

Suppose I represent my game logic in systems like so:

public sealed class PhysicsSystem : IExecuteSystem
{
    private readonly IPhysicsService _physics;
    private readonly ITimeService _time;
    private readonly IPhysicsConfig _physicsConfig;

    public PhysicsSystem(IPhysicsService physics, ITimeService time, IPhysicsConfig physicsConfig)
    {
        // Initialization
    }

    public void Execute()
    {
        // Logic goes here
    }
}

I have dozens of these systems, nearly all of which depend on some common services or configuration objects. To keep my code manageable, I group them in System-like objects called Features. This results in a logical tree-like structure. Here's an example:

public sealed class GameplayFeature : Feature
{
    public GameplayFeature()
    {
        Add(new PhysicsSystem(/* ... */));
        Add(new AiFeature(/* ... */));
    }
}

Note that the order in which these systems are declared and added is important.

The naive thing would be to register every System and Feature, with the top-most Feature -- let's call it FullGameFeature -- having an enormous constructor that passes in every possible dependency in my game. This is not feasible.

So what would you suggest? My requirements are:

• The ability to initialize individual systems with constructor injection
• The ability to define each of a Feature's Systems within its constructor
• The ability to keep the overall tree structure of my Systems and Features

One thing I won't do is to inject the IObjectResolver into all Features and Systems, as my current home-grown dependency injection framework already does something similar to that. If VContainer requires me to do this, then there will be no advantage in adopting it.

[JesseTG]

I have decided to bite the bullet and just use a big-ass constructor. My PhysicsSystem as defined in the original post is unchanged.

My GameplayFeature now looks like this:

using VContainer;

public sealed class GameplayFeature : Feature
{
    public GameplayFeature(
        PhysicsSystem physics,
        AiFeature ai
    )
    {
        Add(physics);
        Add(ai);
    }

    public static void Register(IContainerBuilder builder)
    {
        builder.Register<GameplayFeature>(Lifetime.Singleton);
        builder.Register<PhysicsSystem>(Lifetime.Singleton);
        AiFeature.Register(builder); // Implementation is similar to this one, but with AiFeature's systems and sub-features
    }
}

(This particular constructor is small, but I have several like it that are larger.)

[hadashiA]

Hello. Sorry for the late response.
I have a few suggestions.

1. I recently added the feature to set up an instance using a lambda expression. #206

So, how about the following statement.

builder.Register(container =>
{
    var feature = new GamePlayFeature();
    feature.Add(container.Resolve<PhysicsSystem>());
    feature.Add(contaienr.Resovle<AiFeature>());
    return feature;    
},  Lifetime.Singleton)

In this case, we will be using the IObjectResolver directly, but we can isolate only the settings.

( You may also want to create an extension method to IObjectResolver to make it easier to write the above.
(Just like the various DI methods in ASP.NET Core.

2. Maybe we can Resolve it as a collection

You can register multiple instances of the same type, and then Resolve the collection.
How about the following?

builder.Register<System, PhysicsSystem>(Lifetime.Scoped);
builder.Register<Syste, FooSystem>(Lifetime.Scoped);
// ...
builder.Register<GamePlayFeature>(Lifetime.Singleton);

class GamePlayFeature
{
    public GamePlayFeature(IReadOnlyList<System> systems)
    {
        foreach (var system in systems)
        {
            Add(system);
        }
    }
}

[JesseTG]

Hello. Sorry for the late response.

Not a problem. I'm in love with VContainer, I don't know how I lived without it.

I have a few suggestions.

1. I recently added the feature to set up an instance using a lambda expression. #206

So, how about the following statement.

builder.Register(container =>
{
    var feature = new GamePlayFeature();
    feature.Add(container.Resolve<PhysicsSystem>());
    feature.Add(contaienr.Resovle<AiFeature>());
    return feature;    
},  Lifetime.Singleton)

In this case, we will be using the IObjectResolver directly, but we can isolate only the settings.

( You may also want to create an extension method to IObjectResolver to make it easier to write the above.
(Just like the various DI methods in ASP.NET Core.

Where would I register PhysicsSystem and AiFeature?

2. Maybe we can Resolve it as a collection

You can register multiple instances of the same type, and then Resolve the collection.
How about the following?

That won't work because I have several levels of nesting, i.e. GameplayFeature has Features which in turn contain other Features and Systems, and then those Features contain other Features and Systems, and so on.

[hadashiA]

I'm in love with VContainer, I don't know how I lived without it.

:)

Where would I register PhysicsSystem and AiFeature?

Ah, yes. In this case, Register must be written explicitly. e.g:

builder.Register<FooSystem>(Lifetime.Transient);
builder.Register<BarSystem>(Lifetime.Transient);

builder.Register<AiFeature>(container =>
{
    var feature = new AiFeature();
    feature.Add(container.Resolve<FooSystem>());
    // ...
   return feature;    
}, Lifetime.Singleton)


builder.Register<GamePlayFeature>(container =>
{
    var feature = new GamePlayFeature();
    feature.Add(container.Resolve<AiFeature>());
    feature.Add(container.Resolve<BarSystem>());
    // ...
   return feature;    
}, Lifetime.Singleton)

It's not very concise.
I am thinking a little about providing an extension method.

public class FeatureOptions
{
    readonly IContainerBuilder builder;
    public readonly List<Type> SystemTypes = new List<Type>();
            
    public FeatureConfiguration(IContainerBuilder builder)
    {
        this.builder = builder;
    }

    public void Add<TSystem>()
    {
        builder.Register<TSystem>(Lifetime.Transient);
        systemTypes.Add(typeof(TSystem));
    }
}

public static class ContainerBuilderExtensions
{        
    public static void RegisterFeature<TFeature>(
        this IContainerBuilder builder,
        Action<FeatureOptions> configure) where TFeature : class, new()
    {
        var options = new FeatureOptions(builder);
        configure(options);
        builder.Register(container =>
        {
            var feature = new TFeature();
            foreach (var system in options.SystemTypes)
            {
                feature.Add(system);
            }
            return feature;
        }, Lifetime.Singleton);
    }
 }

This could probably be used as follows:

builder.RegisterFeature<AiFeature>(options =>
{
    options.Add<FooSystem>();
});

builder.RegisterFeature<GamePlayFeature>(options =>
{
    options.Add<AiFeature>();
    options.Add<BazSystem>();
});

2. Maybe we can Resolve it as a collection
   That won't work because I have several levels of nesting,

Ah, I see.

[SewerynVixa]

Hi,
I'm also trying to do similar thing and also considered approach you marked as the answer.

Finally, I decided to go with approach showed here: sschmid/Entitas#689 (comment)
This is for Zenject but also works with VContainer (my case).

This is class that I have in VContainerSettings

public class ProjectScope : LifetimeScope
            {
                [SerializeField] private ScriptableObjectInstaller[] installers = default;
                [SerializeField] private ContextController contextControllerPrefab = default;
      
                private ContextController contextControllerInstace;
      
                protected override void Configure(IContainerBuilder builder)
                {
                    foreach (var scriptableObjectInstaller in installers)  
                    {
                        scriptableObjectInstaller.Install(builder);
                    }
      
                    builder.RegisterInstance(Contexts.sharedInstance);
                    contextControllerInstace = Instantiate(contextControllerPrefab);
                    builder.RegisterInstance(contextControllerInstace);
                    builder.RegisterBuildCallback(CreateContextController);
                }
      
                private void CreateContextController(IObjectResolver resolver)
                {
                    resolver.Inject(contextControllerInstace);
                    contextControllerInstace.Init();      
                    contextControllerInstace.gameObject.SetActive(true);
                    DontDestroyOnLoad(contextControllerInstace);
                }
            }

And this my entry point for creating all systems

public abstract class ContextController : MonoBehaviour
            {
                [Inject] protected IObjectResolver container = default;
                [Inject] protected Contexts contexts = default; 
      
                protected InjectableFeature Systems;
      
      
                public virtual void Init()
                {
                    Systems = new InjectableFeature();
                    CreateSystems(contexts, Systems); //overwritten in class for given game
                    Systems.IncjectSelfAndChildren(container);
                    gameObject.SetActive(true);
                }
                ...
           }

What you think about this approach?

I don't like that constructor is useless for Systems if you need some data from injected Services (etc.), for that I'm using IIntializable interface.