evaneos/dic-it

Yet another dependency injection container

Maintainers

👁 oliviermadre

Package info

github.com/Evaneos/dic-it

Homepage

pkg:composer/evaneos/dic-it

Statistics

Installs: 70 174

Dependents: 1

Suggesters: 0

Stars: 0

v2.2.1 2013-11-01 00:00 UTC

Requires

Suggests

Provides

None

Conflicts

None

Replaces

None

MIT a2f19d95b71a49fe2a651168b67aef7ad7b17896

This package is auto-updated.

Last update: 2026-06-22 20:25:25 UTC


README

DIC-IT is a simple dependency injection container, with extensible activation & injection strategies.

Setup

The recommended setup is to create a config folder at the root of your repository. All configuration is based on YAML files.

Sample YAML file :

parameters:
 MyParameter: 'Some parameter value'
 MyOtherParameter: 42
 MyParameters:
 nested_level:
 foo : foo
 bar : bar
 baz : foobar
classes:
 MyServiceName:
 class: \Fully\Qualified\ClassName
 arguments: [ @MyDependency, %MyParameter, %MyParameters.nested_level, 'Hard-coded value', $container, $env.ENV, $const.ROOT_PATH ]
 MyDependency:
 class: \Fully\Qualified\DependencyClassName
 props:
 MyProperty: %MyOtherParameter

References

You can inject different kind of references inside class definitions. You can get other service instances, parameters, the container itself, env variables, and constant values.

  • @ServiceName : fetch an instance of that definition
  • %param : fetch a parameter defined in the container
  • $container : fetch the container itself
  • $env.ENV_NAME : fetch an environment variable
  • $const.CONST_NAME : fetch a global defined constant value

Using includes

The configuration can be split into multiple files to ease management of your dependencies :

includes:
 - relative/file.yml
 - relative/another-file.yml
 
classes:
 ...

This allows you to separate parameters from service definitions for example.

Default object life-cycle

By default, all objects are created as non-singleton (this will definitely change) objects, so every time a reference is resolved by the container, a new instance of the requested object is created.

Managing circular dependencies

By default, circular dependencies are not handled well (stack overflow...) due the default object life-cycle. To enable circular dependencies for a given object, at least one of the two objects must be defined as a singleton. This however will not yield the expected results, so it is highly recommended to define both objects involved in the circular dependency as singletons.