I was not sure if better to ask here, or on GameDev Stack Exchange. I believe it carries over to general programming.

Context

• I am using Unity3D and building an Online Multiplayer Game.
• I would like to use Constructor Dependency Injection, so no "magic" reflection to keep things simple and be able to view my dependencies more clearly.
• I would like to have Sub Injector Classes that will resolve dependencies.

For Example when I spawn a Player into the game world the root PlayerScript will be an Injector that will Resolve all of the Players Dependencies.

The Player will have a servicecollection and then it will Construct each Service the Player needs to function.

Problem

The Player Injector becomes a large list of Constructing the Services the player needs. I am trying to use SOLID principles, so by splitting my player services into many smaller services. This might mean having 20-30 services on the player. It just feels wrong to have 20-30 lines of code constructing each services and passing them their dependencies.

This is kind of what it is looking like if it wasnt in Unity3D.

Outside of Unity Example

        //PlayerMovement
       Services.Add<CharacterController>(new CharacterController(Inj 1,Inj 2, Inj 3));

        //PlayerInputs
        Services.Add<UIInputs>(new UIInputs(Inject 1,Inj 2, Inj 3));
        Services.Add<InventoryInputs>(new InventoryInputs(Inject 1,Inj 2));
        Services.Add<MovementInputs>(new MovementInputs(Inj 1,Inj 2, Inj 3));
        Services.Add<InteractionInputs>(new CrossHair(Inj 1,Inj 2));

        //PlayerInventory
        Services.Add<InventoryStateManager>(new InventoryStateManager(Inj 1,Inj 2, Inj 3));
        Services.Add<PlayerInventory>(new PlayerInventory(Inj 1,Inj 2, Inj 3));
        Services.Add<CursorInventory>(new CursorInventory(Inj 1,Inj 2, Inj 3));
        Services.Add<ActionBarInventory>(new ActionBarInventory(Inj 1,Inj 2, Inj 3));

        //PlayerUI
        Services.Add<PlayerUI>(new PlayerUI(Inj 1,Inj 2, Inj 3);
        Services.Add<InventoryViewManager>(new InventoryViewManager(Inj 1,Inj 2, Inj 3));
        Services.Add<PlayerInventoryView>(new PlayerInventoryView(Inj 1,Inj 2, Inj 3));
        Services.Add<CursorInventoryView>(new CursorInventoryView(Inj 1,Inj 2));
        Services.Add<ActionBarInventoryView>(new ActionBarInventoryView(Inj 1,Inj 2, Inj 3));
        Services.Add<StorageInventoryView>(new StorageInventoryView(Inj 1,Inj 2));
        Services.Add<ActionBarSelection>(new ActionBarSelection(Inj 1,Inj 2, Inj 3));
        Services.Add<CrossHair>(new CrossHair(Inj 1,Inj 2, Inj 3));

Unity Differences - Only Read If Interested in how I implimented using Unity.

In unity you cannot construct monobehaviour classes. So instead you have to find all of your dependencies that already exist on the player.

I did that by adding IService interface to all Monobehaviours in the Scene. When Player Spawns into the server it will find all IServices, and then I will Inject the dependencies by calling an Initialization Function on each Service.

The Question

Is it normal to have a lot of Services Constructed in one Injector Class?

Please correct me if I have a misunderstanding here.

CodePudding user response：

It is totally normal that injections constructed in one class, that's actually what it is for. You can easilly control and see your dependencies at single place but you should be aware that if you're services are monobehaviour then probably it is not a service. That class Also called as Context generally and there can be more than one context.

You're current injections aren't services, they are more like views that player see. generally views don't do logic but it is also a must that monobehaviour be inside views like player movement.

You can think that views are unity related things and you clamp unity related things as views. Services are used widely as the game runs and don't have related things to the unity. i.e IAuthService for Steam, Epic games, Xbox etc or SettingsService for different OSs.

Many people names their classes names as PlayerController, UiManager/Service without realazing. What they try to achieve looks like always MVC but in a messy way. What i said is also looks almost identical to MVC(S). I think you should look at MVC(S) architectural pattern and get some inspiration.

There's already a framework that supports MVCS IoC, it is Strange, you should definetly check it.