aelf Tech Talks: Dependency Injection Part 4
The Three Dimensions of Dependency Injection
DI’s three dimensions
In this final part, we’ll briefly talk about the three dimensions of dependency injection technology, each of which are complementary.
1) Object combination
That is, the combined root configures the dependencies.
2) Lifecycle Management
We only said that the combination root is the placement to set the dependency. In fact, while setting the dependency, the dependency injection also requires managing the life cycle of each object.
We already know that when applying DI, the dependencies are set in the combined root. We can also refer to the object or method of the combined object as a composer. The combiner is a unified term, which refers to the object that the assembly depends on. Or method. In general, a DI container is a combiner.
Due to the existence of the combiner, the object is destined to not manage the creation of its dependencies. What is the destruction of dependence? If the dependencies are not destroyed in time, there is a risk of memory leaks.
Anyone who has used .NET knows that the GC will automatically reclaim objects that will not be used and if we implement the IDisposable interface, we can destroy the objects ourselves.
In DI, the lifecycle of an object is managed by a combiner. The combiner can decide whether a dependent object is shared among other different objects, or it can decide when to release the object: whether it is released beyond the scope of a certain consumer or is released beyond the role of all consumers.
The management of the object life cycle should be one of the most complicated problems in dependency injection. Let’s take a look at Microsoft’s repo, called Extensions, to support the implementation of dependency injection. This project specifies All objects have three lifestyles, defined in `ServiceLifetime`. The word itself means lifestyle or work style, and it seems to be translated into a life cycle type. These three lifecycle types may be better understood in the perspective of DI containers, but the proposition of managing object lifecycles also exists when not using DI containers. These three categories still apply:
- Singleton. The same instance of abstraction is always shared throughout the application.
- Scoped. Using a singleton for a given role, but provides different instances for different scopes.
- Transient. Each request will return a new instance.
3) Intercept
In theory, Aspect-oriented programming(AOP) can be implemented in decorator mode if the code implementation complies with the SOLID principle. The general approach is to create a subclass named XXServiceDecorator for the previous XXService, inject XXService as a constructor parameter into the XXServiceDecorator, and re-implement the XXService method in the XXServiceDecorator to intercept, in general, directly call, before and after conditions. Finally, set the XXServiceDecorator instead of XXService on the combined root.
Note: there are two other ways to implement AOP, Dynamic Interception (also called dynamic proxy) and Compile-Time Weaving (also called IL weaving). We will not talk about these two topics.
— Join the Community:
· Get on our Telegram Discord Slack and Kakao channel
· Follow us on Twitter Reddit and Facebook
· Read weekly articles on the aelf blog
· Catch up with the develop progress on Github
· Telegram community in 한국 ,日本語 ,русский ,العربية ,Deutsch ,ItalianoandTiếng Việt,
· Instagram: aelfblockchain
· YouTube Channel: aelf
For more information, visit aelf.io
