dependencies

Aedi, a dependency injection library.

Aedi is a dependency injection library. It does provide a set of containers that do IoC, and an interface to configure application components (structs, objects, etc.)

Aim: The aim of library is to provide a dependency injection solution that is feature rich, easy to use, easy to learn, and easy to extend up to your needs.

This tutorial will show how to register several components, and reference them as dependencies.

Just registering a component with predefined data, is not enough even in smallest applications, since an application is an amalgamation of interconnected components. Therefore the framework does allow client code to register components that have dependencies, and reference them in configuration of those components.

For example, in application that simulates cars, a car clearly is not a single god object. It is a set of interconnected components, represented by objects in application. Though as seen in listing, the car has it’s color and size hard-coded to specific values, and modifications to them aren’t possible to do. Having a car simulator such code is not desired, since a simulator should be able to simulate multiple types of cars with different sizes and colors.

1 class Car {
2     private Color color_;
3     private Size size;
4 
5     public this() {
6         color_ = Color(255, 255, 100);
7         sizes = Size(200, 150, 500);
8     }
9 }

In improvement to the defined car in application (above), could be done by exposing color and size of car to configuration from exterior environment

1 class Car {
2     private Color color_;
3     private Size size;
4 
5     public this(Size size) {
6         this.size = size;
7     }
8 
9     public @property void color(Color color) {
10         this.color_ = color;
11     }
12 }
13 
14 void main() {
15     Car myCar = new Car(Size(200, 150, 500));
16     myCar.color = Color(0, 255, 0);
17 }

Having the ability to change color and size of a car it is possible to have now multiple instances of a car, with different sizes and colors, though with increase of different types cars, the amount of code required to instantiate and configure them with right sizes increases tremendously, and in the end can become complex, and cumbersome to understand. Not to mention, the importance of micromanaging the order of how cars component instantiate. A car cannot be instantiated before, her components. Clearly the solution is more flexible, yet at a cost of increased amount of code.

A DI framework aims to lessen the burden of writing wiring code, and will eliminate the need of micromanaging the order component creation. It will do instead of developers, just like in following example

1 SingletonContainer container = singleton(); // Creating container that will manage a color
2 
3 with (container.configure) {
4 
5     register!Color // Register color into container.
6         .set!"r"(cast(ubyte) 0) // Set red color to 0
7         .set!"g"(cast(ubyte) 255) // Set green color to 255
8         .set!"b"(cast(ubyte) 0); // Set blue color to 0
9 
10     register!Size // Register a size into container
11         .set!"width"(200UL) // As for color set width to 150.
12         .set!"height"(150UL)
13         .set!"length"(500UL);
14 
15     register!Car // Register a car in container
16         .construct(lref!Size) // Construct car using size present in container
17         .set!"color"(lref!Color); // Set car color to color present in container.
18 }
19 
20 container.instantiate(); // Boot container (or prepare managed code/data).
21 
22 container.locate!Car.print;

Referencing a dependency in a Car can be done using lref!Type notation, that allows framework to detect that a dependency is actually required to pass, and not a simple value. Therefore the framework will search for a value of a type Type and pass it as a dependency to Car. The result of a container can be seen by fetching a car from container and printing it to the stdout

At end we should see the car:

You bought a new car with following specs:
Size:	Size(200, 150, 500)
Color:	Color(0, 255, 0)

Try example in this module. Modify it, play with it to understand how to configure dependencies between components.

Members

Classes

Car
class Car

A class representing a car.

Structs

Color
struct Color

A struct that should be managed by container.

Size
struct Size

Size of a car.

Meta

Authors

aermicioi

License

Boost Software License - Version 1.0 - August 17th, 2003

Permission is hereby granted, free of charge, to any person or organization obtaining a copy of the software and accompanying documentation covered by this license (the "Software") to use, reproduce, display, distribute, execute, and transmit the Software, and to prepare derivative works of the Software, and to permit third-parties to whom the Software is furnished to do so, all subject to the following:

The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software, unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.