Should EntryPoint's be used for dynamically created objects?

[Raindery]

I started using VContainer in a new project (I was using Zenject before). I liked the idea, but during the implementation of the enemy factory a problem arose. I want to use the approach that is described in the documentation, i.e. separating logic from presentation and IoC. I am also guided by the rule:

In VContainer, injection of MonoBehaviour is recommended over injection into MonoBehaviour

I have such a class structure:

As a Passive View, I use a class like this:

[RequireComponent(typeof(CharacterController))]
public class EnemyEntity : MonoBehaviour
{
    [SerializeField, ReadOnly] private CharacterController _characterController;

    private Transform _cachedTransform;

    public Transform Transform
    {
        get
        {
            if (_cachedTransform == null)
                _cachedTransform = transform;
            
            return _cachedTransform;
        }
    }
    

    private void OnValidate()
    {
        if (_characterController == null)
            _characterController = GetComponent<CharacterController>();
    }

    public void Move(Vector3 movement)
    {
        _characterController.Move(movement * Time.deltaTime);
    }
}

Presenter (logic)

public class EnemyPresenter : ITickable
{
    private readonly Player.Player _player;
    private readonly IEnemyBrain _enemyBrain;


    public EnemyPresenter(Player.Player player, IEnemyBrain enemyBrain)
    {
        _player = player;
        _enemyBrain = enemyBrain;
    }
    

    public void Tick()
    {
        if (_player == null)
            return;
        
        _enemyBrain.MoveToTarget(_player.Transform.position);
    }
}

And other dependency

public interface IEnemyBrain
{ 
    void MoveToTarget(Vector3 targetPosition);
}

public class EnemyBrain : IEnemyBrain
{
    private readonly EnemyEntity _enemy;
    
    
    public EnemyBrain(EnemyEntity enemy)
    {
        _enemy = enemy;
    }

    public void MoveToTarget(Vector3 targetPosition)
    {
        var moveDirection = (targetPosition - _enemy.Transform.position).normalized;
        moveDirection.y = 0f;
        
        _enemy.Move(moveDirection * 5f);
    }
}

I tried to create a different Scope for each enemy - it works, and it's convenient, but it's not the best solution. The only solution I found is to manually resolve dependencies in the factory through the constructor, but in this case you can't get EntryPoint benefits because they can't be registered at runtime.

So, my question is - is it worth using EntryPoint's and basically sticking to this approach in this case? How to resolve such dependencies properly?
So far it seems to me that VContainer is suitable for relatively single dependencies, like InputService, UI, etc. And for factories, the usual MonoBeahaviour approach is supposed to be used.

Thank you all for the answers! I hope you will help me 🙌

P.S. I realize that I may be overengineering, but I'm still interested in figuring it out :)

[Raindery]

So, I experimented a bit and it turns out that EntryPoints registered as Transient work as expected for several reasons:

• after registration they immediately start working in the PlayeLoopSystem, even though I don't resolve anywhere.
• When I resolve them several times (for example in the factory) a new instance is created, but it does not work in PlayerLoopSystem.

So EntryPoint's are not suitable for dynamically created objects in the current form, if I understand correctly.

Is this a bug?

Now my question is this - How to separate the logic in the case above? Should I implement my own PlayerLoop? 😁

[a-gos]

Hi! I am also facing a similar issue, and I believe the core of this is trying to follow this recommended approach

In VContainer, injection of MonoBehaviour is recommended over injection into MonoBehaviour

I understand the idea behind this affirmation and agree with it. But when working in a real case it just gives more problems than it solves.
My architecture is similar to yours:

• Passive View
• Service
• Model

And the communication should be done in this way: Model -> Service <- View.

So basically I was registering my Service as a Entry point and the View injected into it. This works perfectly for objects that are already on Scene. But when trying to follow this approach with dynamically created objects it fails to work.

Since Service are the ones that receive the injected View, they need to have some mechanism to handle the View state:

• They should be aware of when a View is created
• When this View has been initialized or destroyed to handle event cleaning for example.
• If I want to have multiple instances of a view with multiple services and multiple models I am not sure on how this would work.

Not sure what would be the best solution to this... I was thinking that maybe a MVVM approach would suit the case, but everything comes back to the same issue so I believe the solution would be more of an architectural design choice. Probably some kind of mechanism that once a View is created it bind it to a specific Service and into this service the necessary dependencies are resolved.

But then, it also seems like this is the start to overengineering for small projects. To be honest right now I spend more time fighting with the architecture of the code that developing the game 🥲

Please let me know if you have some idea for this, I believe a unify architecture is possible but thinking alone is hard to find the best solution

[Raindery]

Hello! Thank you for reply!

So far I see one solution is to implement a custom PlayerLoop that is tied to a single EntryPoint, like EnemyDirector or something like that. But unfortunately I haven't had a chance to think about it well enough yet 😁. VContainer will play a minimal part in this - you'll have to keep track of the life of the objects yourself.

But then, it also seems like this is the start to overengineering for small projects. To be honest right now I spend more time fighting with the architecture of the code that developing the game 🥲

I understand you 🤝 But I want to go deeper and figure it out :)
For small projects, I think something like Boss Room would be good. It's a project developed by Unity, they use VContainer there mainly for singltones, the rest is classic. But I didn't like this approach - it's too mixed.

So as soon as I manage to realize the solution, I will post in this thread :) Also if you are the first to find a solution, I will be glad if you post here too

[a-gos]

Thanks! Will take a look at this Boss Room project and yes will let you know any advances I make on this. I feel like there should be a good approach to create a nice architecture and is just a matter of time. Let's see how this ends up 👌