Download the PHP package talesoft/tale-di without Composer

Tale DI

What is Tale DI?

Tale DI is a lightweight implementation of the PSR-11 Dependency Injection spec will full auto-wiring support.

The API might still change here and there.

Installation

Usage

ContainerBuilder

use Tale\Di\ContainerBuilder;

Using the ContainerBuilder, you can auto-wire a fully working DI container including full PSR-6 cache support.

The container returned will be a Tale\Di\Container which is explained below.

Service Locators

If you don't want to add every single file manually, you can also use one of the three service Locators that come with Tale DI.

Injections and philosophy

Tale DI, by design, only allows constructor injections. There are no optional dependencies that are not covered in a constructor and there are no XyzAware interfaces and no possibility to do it.

This avoids a lot of magic and defensive null checks all over your code. If this is not what you like, Tale DI might not be what you're looking for. I suggest you give it a try anyways.

Injections happen simply by class name or an interface it implements:

It doesn't matter if you ever added the dependency to the container, it will auto-wire any external (or internal) dependency that has a readable type (and even that can be handled). This is possible because Tale DI works solely based on PHPs existing class mechanisms, interfaces and reflection.

Optional dependencies work as expected and should be defaulted to default/null implementations so no defensive null checks are required.

Iterables and Arrays of interfaces

Tale DI has a notion of Tags specified through plain PHP interfaces. You can inject by using interfaces:

and through proper type-hinting in the doc-comment you can even inject all instances of a specific interface:

This will inject all known dependencies of type WorkerInterface into the workers argument.

Parameters

Tale DI can't only inject classes and instances, you can specify fixed parameters that are injected based on their names. Notice they should be serializable to make use of the caching mechanisms.

The second parameter allows you to reduce the parameter to be used on a specific class or interface only.

This also allows creating instances of external types without requiring a specific factory for it:

Manually construct container

The base setup of the container is pretty simple. Most of the stuff is used for the auto-wiring mechanism, but you can also completely avoid the ContainerBuilder and use containers directly.

Tale DI brings three base containers with it that you can use for their specific purposes.

Container

use Tale\Container;

The Tale Container and the heart of the DI system is a container that resolves values through specific Tale\Di\DependencyInterface instances. This is how it works:

You can always define own dependency types and how they are resolved by implementing Tale\Di\DependencyInterface:

ArrayContainer

use Tale\Di\Container\ArrayContainer;

Mostly useful for testing, this is a really basic implementation of PSR-11 that just maps fixed names to values

NullContainer

use Tale\Di\Container\NullContainer;

A Null Container that always returns false when calling ->has() and always throws a NotFoundException when calling ->get().

This is mostly useful as a default container for classes that want to decorate containers as an optional dependency and require a default implementation to avoid defensive null checks.

Type Information

use Tale\Di\TypeInfoFactory\PersistentTypeInfoFactory;

Notice this will probably end up in an own library at some point.

Parameter Reader

use Tale\Di\ParameterReader\DocCommentParameterReader;

A parameter reader that also takes into account doc comment @param-annotations