Go to file
2017-08-13 17:18:04 +02:00
example Update copyrights 2017-02-13 20:20:35 +01:00
source/poodinis Fix template class injection 2017-08-13 17:18:04 +02:00
test/poodinis Update copyrights 2017-02-13 20:20:35 +01:00
.gitignore Add registerOnResolveExample to .gitignore 2016-06-26 21:45:48 -06:00
.travis.yml Revert minimal D compatibility to 2.068.2 2016-12-26 18:17:51 +01:00
CHANGES.md Prepare version 8.0.0 release 2016-12-26 18:38:36 +01:00
dub.json Use SCOD to style ddox 2017-02-26 17:48:57 +01:00
LICENSE.txt Update copyrights 2017-02-13 20:20:35 +01:00
README.md Fix headers in readme 2017-07-29 16:36:50 +02:00
TUTORIAL.md Fix headers in tutorial 2017-07-29 16:40:22 +02:00

Poodinis Dependency Injection Framework

Version 8.0.0
Copyright 2014-2017 Mike Bierlee
Licensed under the terms of the MIT license - See LICENSE.txt

Master: Build Status - Dev: Build Status

Poodinis is a dependency injection framework for the D programming language. It is inspired by the Spring Framework and Hypodermic IoC container for C++. Poodinis supports registering and resolving classes either by concrete type or interface. Automatic injection of dependencies is supported through the use of UDAs or constructors.

Requires at least a D 2.068.2 compatible compiler
Uses the Phobos standard library
Can be built with DUB 1.1.1 or higher

Features

  • Member injection: Injection of dependencies in class members of any visibility (public, private, etc.)
  • Constructor injection: Automatic injection of dependencies in class constructors on creation.
  • Value injection: Value-types such as primitives or structs can be injected using custom value injectors.
  • Type qualifiers: Inject concrete types into members defined only by abstract types.
  • Application contexts: Control the creation of dependencies manually through factory methods.
  • Multi-threadable: Dependency containers return the same dependencies across all threads.
  • Minimal set-up: Creation and injection of conventional classes requires almost no manual dependency configuration.
  • Well-tested: Developed test-driven, a great number of scenarios are tested as part of the test suite.

See the TUTORIAL.md and examples for a complete walkthrough of all features.

Getting started

DUB Dependency

See the Poodinis DUB project page for instructions on how to include Poodinis into your project.

Quickstart

The following example shows the typical usage of Poodinis:

import poodinis;

class Driver {}

interface Database {};

class RelationalDatabase : Database {
	private Driver driver;

	this(Driver driver) { // Automatically injected on creation by container
		this.driver = driver;
	}
}

class DataWriter {
	@Autowire
	private Database database; // Automatically injected when class is resolved
}

void main() {
	auto dependencies = new shared DependencyContainer();
	dependencies.register!Driver;
	dependencies.register!DataWriter;
	dependencies.register!(Database, RelationalDatabase);

	auto writer = dependencies.resolve!DataWriter;
}

Dependency set-up can further be reduced by enabling "Register on resolve". For more details and examples, see the examples directory.

Documentation

You can find the public API documentation here.

Alternatively you can generate documentation from the source code using DUB:

dub build --build=ddox

The documentation can then be found in docs/

History

For a full overview of changes, see CHANGES.md

Value Injectors

Poodinis doesn't come with implementations of value injectors. Value injectors are available in separate projects:

Have you made any or do you know of any? Please add them to this section via a pull request or open an issue.

Projects Using Poodinis

  • Eloquent: A lightweight web application written in D
  • ioc: Slow approach to Inversion of Control in D2 language

Future Work

  • Component scan (auto-registration)
  • Phobos collections autowiring
  • Named qualifiers

Contributing

Any and all pull requests are welcome! If you (only) want discuss changes before making them, feel free to open an Issue on github. Please develop your changes on (a branch based on) the develop branch. Continuous integration is preferred so feature branches are not neccessary.