In this video, we learn to use the kosDependency decorator to model composite relationships between models.

How to use dependencies to build composite models that draw on smaller related models as building blocks. Understand how model relationships impact the lifecycle. This video looks at model injection, model lifecycle, and the kosDependency decorator.

When we created the model before, we created it as a child.

You may recall in the dispenser model, we have the child decorator, which says that this model will behave as a child to the dispenser model.

Why is that important?

It ties the life cycles together.

It also means that it is truly a containment relationship rather than a composite, in that if the dispenser model were to be destroyed or get removed from the system, all of its children will also be removed from the system, so the two life cycles are intrinsically tied in a parent-child relationship.

That’s not always the case with models.

In this case here with our system info model, the two aren’t necessarily going to be tied.

We already said it’s a singleton.

We already said that it’s going to be showing global data.

We don’t necessarily want the system info model to get destroyed or to have its life cycle so tightly tied to the dispenser model.

To overcome that, we have another way of creating and instantiating these models and declaring dependencies between them, and that’s using a different decorator.

You may recall we started off actually physically instantiating the model here, which is fine and is quite common to do, but in this case we don’t need to do that if it’s really just a dependency.

I can remove this part and change the dependency to a KOS dependency here, and it takes a little bit of information here, which takes a model type.

In this case, it’s going to be the system info model.

I’m going to list this as guaranteed to be there.

Now, what KOS dependency does, it’s utilizing the framework to dynamically inject this model into this class, so by virtue of this decorator being on here, when the dispenser model is getting created, the framework will detect that there is a dependency here and go off and create an instance of the system info model, and it will inject it into this property as part of the life cycle.

Again, the life cycles are tied in that I can declare when I want this dependency to be ready by.

By default, it’s going to be ready as soon as possible.

It’ll be ready in the initialization phase, but I have the ability in the dependency to say which life cycle would I like it to be available, and there is a property here, which is a dependency life cycle enumeration, and I can say I want it available at any one of these life cycle hooks, so I can have it as soon as possible, which is the default.

I can say I want it to be ready when I’m ready, or I want it to be somewhere in between.

I’ll leave it the default for now, and that’s all I need to do in order to actually create that dependency between these models.

Now, it is a dependency, not a parent-child relationship, in that if the dispenser model were to be destroyed, the system info model will still exist.

It’ll still be cached and available if other models need access to it, so it’s not a strict parent-child relationship, it’s more of a reference or a dependency relationship between them.

And again, I can reload my screen, everything still works the same way, but I haven’t had to physically instantiate that model, and this becomes really, really powerful, especially as we start composing things a little bit differently in our models, so you can imagine a number of smaller dependencies that you have that come together in a composite that allows us to get access to those information, without this model necessarily being responsible for knowing how to instantiate or knowing the details, it really just allows it to become injected in at the appropriate time in the life cycle.

What’s interesting is that it’s not at a single level, obviously models can have dependencies on other models and it can continue on, and the framework is really responsible for making sure that everything is ready at the appropriate time.

So you can create these relationships, these complex relationships, with an understanding that by the time you’re ready to use the data, it will be loaded and all of its dependencies will also be realized for you, so it takes a lot of the burden off of the developer to need to manage those dependencies, and not just on creation, but also on removal, right?

So when a model gets destroyed, much the same way that child models will also get destroyed, it’ll clean up other relationships that might exist, and potentially any resources that are being used as a result.

So it’s a really powerful concept and one that you’ll use quite a lot when you’re building out your models.