Download the PHP package weew/container without Composer

Dependency injection container

Table of contents

• Installation
• Creating a container
• Primitive data
• Classes
• Factories
• Interfaces
• Functions and methods
• Singletons
• Wildcards
• Aliases
• Additional methods
• Extensions
  • Doctrine integration

Installation

composer require weew/container

Creating a container

The container has no additional dependencies, so a simple instantiation will do the trick.

Primitive data

Storing any type of data:

Classes

Retrieving classes:

Passing additional parameters:

Resolving constructor dependencies:

Sharing a specific instance:

Factories

Working with factories:

Accessing container from within a factory:

Container is not limited to closure factories, it supports class method and static method factories too:

Traditional callable array syntax is also supported. It does exactly the same as the examples above, but with a slightly different syntax:

All facotires benefit from dependency injection. Additionaly, if you let the container instantiate your factory, it will be resolved trough the container too.

Interfaces

Resolving interfaces:

Sharing specific interface implementation:

Interfaces can have factories too:

Of course you can also type hint interfaces:

Functions and methods

Functions can get resolved by the container:

The same works for closures:

Invoking class methods is also strait forward:

Invoking static methods:

It is possible to use PHP's traditional callable syntax for invocation of functions and methods:

Singletons

Container values can be defined as singletons. A singleton definition will return the same value over and over again. Here is an example of a singleton interface definition:

The same works for classes:

And factories:

Sharing an instance always results in a singleton:

Wildcards

This one might be especially useful when working with factories. Lets take Doctrine for example. You can not simply instantiate a repository by yourself. But still, it would be great if you could have them resolved by the container. Unfortunately, this will throw an error, since the repository requires a special parameter that can and should not be resolved by the container:

However, you might use a wildcard factory. You can use any regex pattern as a mask. Right now, the only supported regex delimiters are / and #.

As you see here, the actual class name MyRepository was passed to the custom factory as the $abstract parameter. From there, we call the RepositoryFactory and tell it to create us a new instance of MyRepository. Afterwards the same factory can be used to create an instance of YourRepository.

Telling the container that all instances produced within this factory should be singletons is very simple:

Wildcards are very powerful, however, they should be used with caution, since they could break your application if you configure them wrong. (for example: if the regex mask is not precise enough and matches unwanted classes). Thanks to regex, creating precise masks shouldn't be a big deal though.

Wildcards can also be used in combination of class names and instances. But I find the usecases for this very limited:

Aliases

If you need to create an alias for a definition, for example when you want to provide a factory for a class as well as for it's interface, and don't want to do it twice for each one, you could create a definition with an alias (or two, or ten). Just provide an array of identifiers. The first element in the array is considered as "the id" and the others are aliases.

The same would work with singletons, primitive values and so on.

Additional methods

Check if the container has a value:

Remove a value from the container:

Extensions

There are additional extension available to make the container even more powerful.

Doctrine integration

The weew/container-doctrine-integration package makes doctrine repositories injectable.