DDI (dynamic dependency injection)
This library provides a generic dependency injection container that can be easily integrated into any application and can be extremely extensible with the extension trait.
Dependency injection is a common design pattern , mainly used in some frameworks such as Rocket, Actix Web, bevy. With ddi you can implement dependency injection without such frameworks, and you can implement your own framework.
Example
use *;
;
let mut services = new;
services.service;
services.service;
services.service_factory;
let provider = services.provider;
assert_eq!;
std feature
ddi supports no-std by default, if std feature enabled the internal data structure will be changed from [alloc::collections::BTreeMap] to [std::collections::HashMap] and [std::error::Error] will be implemented for [DDIError]. This will give a little performance improvement and usability.
sync feature
If sync feature enabled, ddi will support multi-threading and you can share [ServiceProvider] between multiple threads.
! Enabling
syncmay cause your existing code to not compile! This is because enablingsyncrequires instances in the [ServiceCollection] to implementsend + syncandServiceFactoryto implementsend. And default no such restrictions.
Basic Usage
First you need to register all services in the [ServiceCollection], which is a container of all services, [ServiceCollection] stored a series of triplets (type, name, implementation). You can use the [ServiceCollection::service] to add item to it.
For example, the following code will add a item (&str, "default", "helloworld") to the [ServiceCollection]
let mut services = new;
services.service;
Here, the service "implementation" can also be a function, the factory of the service. The factory function is lazy execution, will only be executed when the service is used. For example.
services.service_factory;
The service factory can use parameters to get other services as dependencies. ddi will pass in the corresponding services based on the type of the parameters. Due to the reference rule of rust, the type of the parameter must be an immutable reference type.
services.service_factory;
When you have all the services registered, use [ServiceCollection::provider()] to get the [ServiceProvider], and then you can get any service you want from [ServiceProvider].
let provider = services.provider;
assert_eq!;
Design Patterns
* Wrap your service with [Service<T>] (Arc)
When a service wants to hold references to other services, the referenced service should be wrapped in [Arc<T>] for proper lifecycle handling. ddi defines an alias type Service<T> = Arc<T> for such a pattern.
We recommend wrapping all services in [Service<T>] to make cross-references between services easier.
That does not allow circular references, because ddi does not allow circular dependencies, which would cause the [DDIError::CircularDependencyDetected] error.
use *;
;
;
let mut services = new;
services.service;
services.service_factory;
let provider = services.provider;
assert!;
* Use extension trait to expanding [ServiceCollection]
The extension trait makes [ServiceCollection] extremely extensible. The following example shows the use of the extension trait to register multiple services into one function.
use *;
// ------------ definition ------------
;
;
;
// -------------- usage ---------------
let mut services = new;
services.install_database;
let provider = services.provider;
assert!;
* Use [ServiceProvider] in the factory, get other services dynamically
In our previous examples service factory used static parameters to get the dependencies, in the following example we use [ServiceProvider] to get the dependencies dynamically.
use *;
;
;
const SUPPORT_HARDWARE_DECODER: bool = false;
let mut services = new;
if SUPPORT_HARDWARE_DECODER
services.service;
services.service_factory;
let provider = services.provider;
assert_eq!;
* Use service_var or service_factory_var to register variants of service
The [ServiceCollection] can register multiple variants of the same type of service, using service_var or service_factory_var. When registering variants you need to declare ServiceName for each variant, the default (registered using the service or service_factory function) ServiceName is "default".
The following example demonstrates how to build an http server based on service variants.
#[doc(cfg(not(feature = "sync")))]
use *;
type Route = ;
let mut services = new;
services.service_var;
services.service_var;
services.service_factory_var;
services.service_factory;
services.service;
let provider = services.provider;
assert_eq!;
assert_eq!;
assert_eq!;
* Use extension trait to simplify the registration of service variants
In the previous example we used service_var and service_factory_var to register routes for the http server, but the code were obscure and no type checking. The following example demonstrates use extension trait to simplify the definition of routes and solve these problems.
use *;
// ------------ definition ------------
type Route = ;
// -------------- usage ---------------
let mut services = new;
services.install_route;
services.install_route;
services.install_route;
services.install_http;
services.service;
let provider = services.provider;
assert_eq!;
assert_eq!;
assert_eq!;
The install_route function in the example uses the [ServiceFn] trait as argument, which is a powerful type, using the [ServiceFn::run_with] function to automatically extract Fn arguments from the [ServiceProvider] and execute it.
License
This project is licensed under The MIT License.
Credits
Inspired by Dependency injection in .NET.