Question Injection from GameObject Context into instantiated Scriptable Object

I have a question about combination of factory and subcontainer, probably for the issue I already have.

I have a few scriptable object which are instantiated at the beginning of the game based on which one is selected. Also the gameObject which instantiate them has GameObject Context and some classes are bound there. Which one of those classes should be injected into these scriptable objects.

The issue I have that class which is bound in GameObject Context and its MonoInstaller is not injected into my scriptable objects constructor. (btw, that gameObject which I said above and instantiate these scriptable object is instantiated at the beginning of the game by another gameObject which is in the scene hierarchey)

After a little investigation I find out probably I should use combination of BindFactory and FromSubContainerResolve but I can't figure out how to fit that in my current system.

My factory implementation is in this way: (Though I'm not sure if it is better to work in this way or it is better to use PlaceholderFactory)

Code (CSharp):

1. public class ZenjectResourceFactory : IResourceFactory
2. {
3.    private readonly DiContainer _container;
4.  
5.    public ZenjectResourceFactory(DiContainer container)
6.    {
7.        _container = container;
8.    }
9.  
10.    public Object Instantiate(Object [USER=646077]@object[/USER])
11.    {
12.        Object instance = Object.Instantiate([USER=646077]@object[/USER]);
13.        _container.Inject(instance);
14.        return instance;
15.    }
16.  
17.    public Transform Instantiate(Transform transform)
18.    {
19.        Transform obj = _container.InstantiatePrefab(transform).transform;
20.        return obj;
21.    }
22.  
23.    public Transform Instantiate(Transform transform, Transform parent)
24.    {
25.        Transform obj = _container.InstantiatePrefab(transform, parent).transform;
26.        return obj;
27.    }
28.  
29.    public Transform Instantiate(Transform transform, Vector3 position)
30.    {
31.        Transform obj = _container.InstantiatePrefab(transform).transform;
32.        obj.transform.position = position;
33.        return obj;
34.    }
35.  
36.    public Transform Instantiate(Transform transform, Vector3 position, Transform parent)
37.    {
38.        Transform obj = _container.InstantiatePrefab(transform, parent).transform;
39.        obj.transform.position = position;
40.        return obj;
41.    }
42.  
43.    public Transform Instantiate(Transform transform, Vector3 position, Quaternion rotation, Transform parent)
44.    {
45.        Transform obj = _container.InstantiatePrefab(transform, parent).transform;
46.        obj.transform.position = position;
47.        obj.transform.rotation = rotation;
48.        return obj;
49.    }
50. }

 

Man after reading that, I'm glad I don't use Scriptable Objects... Although I can already hear Spiney on his war path, I was never here, you didn't hear anything from me... "These are not the droids you are looking for"...

 

Actually came back to one of my projects after a few years (Even I've not touched Unity for a few years too). I still like Scriptable Objects but I think I'm not fan of Dependency injection anymore but I need it for refactoing some code on my old project. Also look like Zenject/Extenject community is dead so pretty hard to find an answer.
btw, the issue I already have is not because of Scriptable Objects and it is because of dependency injection. Because actually I can easily inject what I want after instantiation directly but because I already use this framework I want to make it in that way. (Because of this I'm not fan of depdency injection at least Zenject and in Unity anymore, things are get very complicated in this way but prbably I'm wrong, really don't want to discuss about pros and cons of depedency injection)

 

All jokes aside, why do you wrap your methods in such a way? Instantiate is meant for creating a gameObject, you are declaring half of these things as transforms. So I am a bit confused, what is the actual goal here?

 

can confirm, old ways, let that go.

 

Yup, actually I shouldn't paste my entire code there. I just use

public Object Instantiate

for instantiating Scriptable Objects so probably I should add something there or entirely change my factory approach.

 

it's potayto/potahto... You just needs things simplified, what is it you want to happen, and what's the best way(per project) for it to happen? There is always several ways to do the same thing.. So whether you follow SOLID principals, or you just do what needs done, it doesn't matter.. As long as you understand it, who cares who doesn't..

But again I ask, are you referring to Object Pooling, or is this more meant for Resource pulling? What is your goal?

 

Not sure it is legal to ever make a constructor for ScriptableObject or MonoBehaviour, or really any class under Unity.

Also, none of the above could ever be called from a field initializer in a MB/SO because those are called on a loading thread, and most of the Unity API is off-limits anywhere except the main thread.

Meanwhile, I like this pattern:

Factory Pattern in lieu of AddComponent (for timing and dependency correctness):

https://gist.github.com/kurtdekker/5dbd1d30890c3905adddf4e7ba2b8580

It has the important advantage that it recognizes Unity is special in constructor land.

 

Yup, you are totally right. By constructor in Scriptable Object I mean, my Constructor function. (One of the reasons which DI is not suitable for Unity because of MonoBehaviour inheritance imo)
Actually Zenject uses [Inject] attribute above the method for method injection.
But I don't think so if my issues is relevant to the link you send here. My factory method is alongside use of Zenject.

Code (CSharp):

1. [Inject]
2. public void Construct(CharacterPowerupContext context)
3. {
4.     _context = context;
5. }

 

Relevant however is why you would ever use Zenject when Unity's built-in dependency injection works perfectly 100% of the time and plays well with everything you will ever integrate from the Asset Store or any "normal" Unity site.

The Unity dependency injection I'm talking about is of course the Scene / Prefab system. It really works perfectly in all cases, and always considers so much of your problem space and details of timing.

Not only that, it is 100% data driven! YES! You can change the outcome of your running code trivially from a constructor standpoint simply by changing Scene / Prefab data. Addressables / Asset Bundles let you remote-control your running game robustly, more robustly than any system you could cobble together.

Why would you ever give that up unless you just like writing boilerplate code?

 

Yup

Yup, you are right and it totally makes sense. I don't really want to discuss about it and I like the way you describe that.
But tbh I just want to overcome this issue in Zenject way instead of removing Zenject from my project or even just use that for SceneContex or ProjectContext stuff.

 

In his defense he said:

So is well understood he's using old methods, and having an issue with new ways..

Can agree, 100% ^, best way to go..

I feel like my methods are being attacked here, but yes, why would one want "to-the-point" code... it's un-thinkable! lol, luv-ya Kurt!

But to be fair, Kurt and Spiney definitely have that realm of logic handled far better than I can, I'm more to the point kinda' guy.. So, I'll back off, my bad.

 

Kurt, WideEye, you two really need to try and actually answer the question in the thread sometime.

Would moving to the use of plain C# classes work here? Scriptable Objects are great but when it comes to instantiating them, I always ask, "Isn't it better to use regular C# classes?" for such a purpose?

In particularly they aren't beholden to the same managed lifestyle of Unity objects, and I imagine would probably play better with dependency injection

You can still use SO's, but I find they're much better when used as factories for these plain C# objects.

 

@Kurt-Dekker
Sorry Kurt but I dont agree.
We have two statements here

1. You are wrong
or
2. I didnt understand what this "Unity DI" means

You can not inject a lot of stuff automatilcy. Only by hands. When we talk about hands we talk about a lot of problems.
For example. I have a simple log system. After some time we have implemented more complex log system with same interface of course.

With zenject I need to change one line of code. Binding in the composition root and propogate this to a lot of dependent classes. How will you achive this level of modularity in different way? Scene and prefab system is not solution here. Zenject about getting dependencies automaticly.

 

Unity DI is called the inspector. There's a lot you can do via the inspector, and we all do it every day. It's surprisingly effective. Even non-coders can use it!

 

I see. No it is not DI. Then my fingers on my hand also DI tools because i use them to inject entities into inspector.
When we talk about zenject we talk about relativly smart framework. Serilized field is attribute, not a framework.

This dependencie need to be propagated to entire system lots of classes. How you will achive this without automatic injection? Lets return to my simple question. I need to inject another implementation of logger to 40 diffrents types. Your opinion? I really want to understand. Serialize field is not a tool it is a hack that makes private field accesiable in the inspector. Private field supposed to be private.

"Even non-coders can use it!"
But you can inject this non-coders works also. Who sad that zenject not allows this option?
The more you give control to inject to human the more error prone our architecture will be. Be cause we are human. We can make mistakes and broke links (git)

Help me understand main thing. How is it possible to handle entire chain of dependencies without delegating sending dependencies from root and without making this process automatic? It is exactly what zenject does. If it is possible using just unity (without reinventing the
wheel ) I will remove zenject today

 

You're conflating the concept of dependency injection with dependency injection frameworks.

Dependency injection is just about fulfilling an object's required references. A constructor is, in fact, dependency injection.

So on that note, the inspector is a form of dependency injection. This cannot be denied. A object requires a reference, and you inject it via the inspector.

It's an important distinction to make, as too many people seem to conflate the concept of DI with DI frameworks, when it's not actually and doesn't need to be that complicated.

Yes DI frameworks can be useful, but they don't replace fundamental programming concepts.

 

"It's an important distinction to make, as too many people seem to conflate the concept of DI with DI frameworks, when it's not actually and doesn't need to be that complicated."

it is among juniours. Among middle and seniours we have diffrent problem
too many people doesnt understand why di frameworks exist.

1. Exactly. DI is raw idea. Zenject just allows us to automate di process. This is why it is required in my opinion. We can make mistakes. Automated process cant. Here we talk about zenject vs unity tools. Not di vs serialized field. Question was how are we going to move from zenject without pain? We cant. DI framework is must have for good architecture. Without exception.

2. Yes we can say that Inpector is some kind of DI because we can inject again...by hands...to one entity...how you will send this dependencie to another 40 entities? Serialize field? No, it is nightmare and bad solution. Writing some code? With DI and DI framworks you done need even to think about it.

3. Zenject is not complicated at all. It is complicated be cause a lot of people dont understand di frameworks.

Summary. Zenject usefull not be cause of it is DI. We can achive DI by hands. It is useful to automate this process and unity doesnt have think kind of functionality. Serialize fields can be used in some way but using it like part of architecture infrastructure... it is not serious.

 

Well first you state the inspector is not DI, then concede it is. So you call out someone for being wrong while being wrong at the same time.

Christ, keep your panties on mate/don't be so insecure about it. No one's telling you that you can't use your favourite framework and I'm not against DI frameworks.

There's any number of ways to manage a project all with their different pro and cons. But just don't shackle yourself to the one method and stop yourself seeing the forest from the trees.

And you know, one method to not have to inject a chain of dependencies is to, you know, not have one in the first place.

This is like saying game objects are a bad idea. It's an essential part of Unity and you're deluding yourself with this belief/not using them.

Any way, this conversation has been groan-worthy enough. I won't be responding again.

 

One last thing to ask. Stop this nonsence if you dont have answers. It is already your third response and I dont see them. Programming it is not religion. You should explain yourself or dont start conversation

It is tenchinal discussion and we can learn from it. It is unity forum we are not at your birthday. Relax.
"be so insecure about it" exactly about you. stop panic and lets asking and answer questions. It is usefull trust me.

Yes there are numbers of ways you are right. Bad ways for bad coders and good ways for experts. Lets try to grow and code better? If you dont want to talk about interesting topic just stop. I need answers not your "be so insecure about it" . A n s w e r s please

 

You're asking a question with which you're only seeking the one answer you want to hear, so there is no point in me answering you. You're coming from the stance of it's the DI way or the highway.

There's plenty of other ways but you obviously don't care.

 

I literally sad to tell me at least about one way to discuss about it. May be you are right and I need to learn something new. Who knows. But I think that you dont understand topic well enought to talk about it but trying to defend yourserlf. Very insecure bro.

 

And I said, "Don't have a big dependency heirarchy". Prevention is the best medicine, as is often said.

Sometimes simpler code is better than complicated code.

 

Please try to understand people around you. You missed the main point.
We dont talk about ourself here. We talk about DI frameworks vs unity tools. I sad that 3 times already. You can use whatever you want. Who sad that topic author me or someone else has small project?

"Sometimes simpler code is better than complicated code."
Yes and I can tell you some secret. DI frameworks were created not to make projects more complex

Dont be angry on me only because im trying to understand you. Cheers.

 

Don't change the question. Your question was:

And my answer fits that question.

 

I see you are litterally troll. I, me, my project, my hierarchy. It is not about you. About entire CHAIN of dependencies. If you have them 5 then dont talk about zenject vs unity tools. It is not your expertise. If you want to talk then dont defend your self and answer questions generaly not about "your" projects

 

I... never mentioned anything about my projects? Not sure where you got that from, mate.

Apparently answering a question makes me a troll. Folks like you are what give DI frameworks a bad rep.

This has to be the dumbest exchange in the history of the forums.

 

"And I said, "Don't have a big dependency heirarchy". Prevention is the best medicine, as is often said."

This is your argument and this is about your project. Stop trolling me

No bro. People just like to talk about things that they dont fully understand. It is normal. Im the same.
I dont want to be right I want to talk about interesting topic to understand this more deep im interested what is alternative. This will be possible when we talk about concepts not about "I have only 5 depedencies". Serialize field is not alternative. If you are not agree simply say your argument. Thats all. When you will work on relativly complex projects with 10 developers you will understand. Without DI it is a hell. And without DI framework it is DI on minimals

I didnt like DI frameworks also but I can not understand today how to work in the spaghetti code. If someone have solution im eager to read.

I will repeat my original question to others.
"How are you going to propagate dependecies to entire eco system without DI frameworks"?

 

That's a great question. You should research it fully and report back here!

Nobody here in Unity land concerns themselves with stuff like that because it's simply not necessary for gamedev. Remember: game started as raw machine language opcodes hand-assembled and burned in one byte at a time.

Meanwhile, as you are on a Unity forum, you'll find answers to how we do work in Unity.

If that's not acceptable to you, well, perhaps you need to find another forum that supports your desires.

 

I hope this thread stays open long enough for me to provide a concrete code example of injecting a loosely coupled dependency upon a logger system to many different classes, that can be easily swapped out via the inspector with zero lines of code, using stock Unity and the inspector. I would love to help someone uninstall Zenject today.

 

A.k.a Prefab.

 

Nad_B wins the thread.

Mods, you may lock this now.

 

Here are two static classes representing two different logger frameworks with different APIs that do different things.

Code (CSharp):

1. using UnityEngine;
2.  
3. public static class LoggerFrameworkA
4. {
5.     public static void LogInformation(string message)
6.     {
7.         Debug.Log($"LoggerA: {message}");
8.     }
9. }

Code (CSharp):

1. using UnityEngine;
2.  
3. public static class LoggerFrameworkB
4. {
5.     public static void Log(LogType logType, string message)
6.     {
7.         if(logType == LogType.Log)
8.             Debug.Log($"LoggerB: {message}");
9.     }
10. }

Here is a MonoBehaviour that has a loosely coupled dependency upon some implementation of an ILogger interface.

Code (CSharp):

1. using UnityEngine;
2.  
3. public class ExampleMonoBehaviour : MonoBehaviour
4. {
5.     ILogger Logger;
6.  
7.     private void Awake()
8.     {
9.         Logger = LoggerSingleton.Instance.GetLogger();
10.     }
11.  
12.     private void OnEnable()
13.     {
14.         Logger?.Log(LogLevel.Information, "Hello world!");
15.     }
16. }

Here is the ILogger interface and LogLevel.

Code (CSharp):

1. public interface ILogger
2. {
3.     void Log(LogLevel logLevel, string message);
4. }

Code (CSharp):

1. public enum LogLevel
2. {
3.     Trace,
4.     Debug,
5.     Information,
6.     Warning,
7.     Error,
8.     Critical,
9.     None
10. }

Here is an abstract ScriptableObject that is also an ILogger.

Code (CSharp):

1. using UnityEngine;
2.  
3. public abstract class Logger : ScriptableObject, ILogger
4. {
5.     public abstract void Log(LogLevel logLevel, string message);
6. }

Here are concrete implementations of Logger that reference one of the different frameworks.

Code (CSharp):

1. using UnityEngine;
2.  
3. [CreateAssetMenu(fileName = nameof(LoggerA), menuName = nameof(LoggerA))]
4. public sealed class LoggerA : Logger
5. {
6.     public override void Log(LogLevel logLevel, string message)
7.     {
8.         LoggerFrameworkA.LogInformation(message);
9.     }
10. }

Code (CSharp):

1. using UnityEngine;
2.  
3. [CreateAssetMenu(fileName = nameof(LoggerB), menuName = nameof(LoggerB))]
4. public sealed class LoggerB : Logger
5. {
6.     public override void Log(LogLevel logLevel, string message)
7.     {
8.         if(logLevel == LogLevel.Information)
9.             LoggerFrameworkB.Log(LogType.Log, message);
10.     }
11. }

And here is a singleton that will inject the dependency into the MonoBehaviour upon request.

Code (CSharp):

1. using UnityEngine;
2.  
3. [DefaultExecutionOrder(-32000)]
4. public class LoggerSingleton : MonoBehaviour
5. {
6.     public Logger Logger;
7.  
8.     public static LoggerSingleton Instance => _instance ??= CreateInstance();
9.     private static LoggerSingleton _instance;
10.  
11.     private static LoggerSingleton CreateInstance()
12.     {
13.         GameObject go = new GameObject(nameof(LoggerSingleton));
14.         return go.AddComponent<LoggerSingleton>();
15.     }
16.  
17.     private void Awake()
18.     {
19.         if(_instance == null)
20.             _instance = this;
21.     }
22.  
23.     public ILogger GetLogger()
24.     {
25.         return Logger;
26.     }
27. }

 

Thanks for your tip but I need your answer not be cause I dont know it. Be cause it will help me to explain to you why DI frameworks exist. It is not for "Look at me". It is usefull communication even if im wrong. For both of us. Lets return to answer. Lets asking question leave learning to me. Dont be so aggresive and emotional.

"stuff like that because it's simply not necessary for gamedev."
You can slice bread with legs even successfuly. No problem. It is necessary if you want to be expert that knows present tools. sorry.

 

God bless you. Thanks for existing in this thread. I will read carefully. Really appreciate such answer. Give me some time. I want to look carefully.

 

Lol.

"I need your answer so I can tell you that you're wrong."

Real constructive attitude there. You won't find your echo chamber here.

 

Thanks one more time for your example. First post with meaning in this absurd theater. Realy interesting. Lets talk about it.

1. As we know static data will not be collected by GC while app running. Memory leak. Not only this. I think we should avoid static data as often as possible.

2. I see that we use singleton here to achive some kind of polymorphism. With it we can "inject" different kind of behaviour like you show us in your example but:
2.1 we are stack with concrete "provider implementation". It is less coupled but not enough. ExampleMonoBehaviour coupled with conrecete implementation of singleton. Main question is or I can say main problem with singletons is "this code is not easly testable". Why make not testable code if we can make it testable?

Lets pretend that these are not problems at all be cause you can fix all of this without DIFramework. I agree.

Lets ask several question to ourself wich will help us to understand why DI Framworks exist:

1. I have decided not use MB for singleton. I want to use plane c# class. What should I do in these case? We have only two options.
1.1 We need to change ExampleMonoBehaviour to getting different implementation of provider be cause we are using concrete provider there.
1.2 We are forced to change CreateInstance method (removing addComponent)

sOlid - closed for "modification" open for extension.
soliD - only logger dependencie was inverted not singleton logger provider.

What if we will use DI framework? We just send provider via nterface to ExampleMonoBehaviour Construct method not using concrete implementation. No need to change code in ExampleMonoBehaviour any more and no need to change code in Singleton that creates mb logger provider. We just need to write new provider and register it to container. thats all.

sOlid - closed for modification open for "extension".
soliD - dependencie inversion

2. In real projects we will have a lot of classes that will use this logger provider. Lets make context and say that we have 40 classes that need logger thus need provider (our singleton). Little project. In how many places we need to change existing code if:
1. We bought or lend some logger that dont have source code (just dll) and we can not use our Logger interface
2. We decide that we dont want to use static because it is waste of memory and this is not only problem about statics.
3. Our project became big and someone decided to write unit tests?

40 classes. May be less because we can use logger provider in base class. What if we will have 500 in one year? Of course we have hands and can fix it. In the old days people used machine code to programm. But it is 21 century lets move with progress.

What with DI framework?.
1. writing new implementation
2. register it in container

no code requires changes. Absolutly zero. It is very important to not break anything.

I will not write more because it is not a book of course. But there are a lot to talk about
If there are exists better way please show me and i will be gratefull. In this discussion winner will be that person who fails. Be cause he will get new knowledge. But be prepare to answer questions. Programming is not religion.

Some people are so lazy to learning new that they will defend their old knowledge with their blood. It is not about you. To you I can say only thanks

 

Explaining existing of DI framework makes you wrong in some way. Of course. Thats why we need to learn. Surprise bro. Im wrong in different domain also. It is normal. Question is why you are so affraid to be wrong? Are you 16? or may be you think that you can not learn from people around you? Why so nervous What about "Insequre" you talked before? Where is it?

Im trying to understand why person thinks in this way before i will start explaining why I THINK he is not right. Yes I have right to think this way we are not tecnical gods and can make mistakes. Even you and your friend. Surprise. Trust me there are a lot of people that know more then you and me. We are not 16. Lets accept criticism with dignity

I need his opinion to find weak point in his understanding. Not to point a finger or destroy him. Dont be a child. But to use right example and words. It is normal strategy if you want to explain something to somebody and its works if he is not mentally 16 years old. You know what I mean.

I dont beleave that you are such troll. I have bad english I want to beleave that it is my fault and im not able to provide information correctly. Be cause if second statement false then I have very bad news for you two.

 

Prefab is by fact smart implementation of Builder Pattern. Very close at least. It is not about automated injection from root. It is a way to build some complex entity with different parts even using code(existing monobehaviour). Prefab is a tool that allows non programmer to build game entity withoud writing code. But you are forced to put this entity after to eco system by hand. Moving to serialized fileds or writing code by hands to load (Resources addressables)

Where is composition root here with automated dependecie injection? With deep and complex dependecie solver? Show me

Stop this prefab nonsence it is not alternative you just dont understand a thing in DI sorry if this is rude but it is true. Before arguing read about DI Framework topic be cause it is not respectful. First understand that domain after lets discuss. Thats the way. Prefab is tool that we use for completely different problem domain. Guys speak with arguments or just stop. It is not serious.

-prefab
-you are not right
- go learn
- scene asset
- he won thread

....cyrcus

 

Mate, nobody likes a preacher.

I think all you're doing it turning more people away from Zenject. So, well done in that regard.

Do your thing, and let us do our thing. It's not your job to tell us what to do.

 

"It's not your job to tell us what to do."
The most insecure thing to say. Who are you exactly to tell you what to do? Im not interested in you at all im interesting in programming. Start learn from others or you will stay at your level forever. I dont want to continue such useless conversation. I have opponent that knows how to use arguments and not emotions like a child. May be we will have someone else soon also. Your thoughts are flood nothing about DI or unity. Zero arguments. Don't attract attention and allow people to talk.
.

"I think all you're doing it turning more people away from Zenject"
Dont learn it. Less compition with programmers when they have your level.
You can use your legs for programming it is your buisness. Go on. Im not interested in you. Im interested in programm architecture. Dont be narcissist.
Zenject is just tool for di not a religion

I understand now. You just completly dont understant this topic and have complexes. Dont be so lazy. Learn something new. You need some exp. We will talk in 5 more years.

"Turning away from Zenject" by posting thoughts and even not from zenject author in unity forum.
I didnt know that im so powerfull DDDDD okey okey. Lets say that people that created DI Frameworks idi*ts but you and your prefab friend understand "real truth" of course) see you bro if you have problem with me and DI call the police

 

Hi if you didnt find any solution I need more information to help you but we can start simple.
Lets find out that your binding step works
Then lets find out that your binding is before you try inject them (yes it is happens is some siutations)

Lets call Debug.Log() with any message before binding statements in installer and another Debug.Log() in scriptable object Construct method. We need to check if they called both and in what order. If it will not tell us something usefull I will ask additional questions