nette/di v3.0.0-alpha1

Nette Dependency Injection Component


Platform: Packagist

Language: PHP

Licenses: BSD-3-Clause/GPL-2.0/GPL-3.0


View on registry:

Nette Dependency Injection (DI)

Downloads this Month Build Status Coverage Status Latest Stable Version License

Purpose of the Dependecy Injection (DI) is to free classes from the responsibility for obtaining objects that they need for its operation (these objects are called services). To pass them these services on their instantiation instead.

Nette DI is one of the most interesting part of framework. It is compiled DI container, extremely fast and easy to configure.

Let's have an application for sending newsletters. The code is maximally simplified and is available on the GitHub.

We have the object representing email:

class Mail
    public $subject;
    public $message;

An object which can send emails:

interface Mailer
    function send(Mail $mail, $to);

A support for logging:

interface Logger
    function log($message);

And finally, a class that provides sending newsletters:

class NewsletterManager
    private $mailer;
    private $logger;

    function __construct(Mailer $mailer, Logger $logger)
        $this->mailer = $mailer;
        $this->logger = $logger;

    function distribute(array $recipients)
        $mail = new Mail;
        foreach ($recipients as $recipient) {
            $this->mailer->send($mail, $recipient);

The code respects Dependency Injection, ie. each object uses only variables which we had passed into it.

Also, we have a ability to implement own Logger or Mailer, like this:

class SendMailMailer implements Mailer
    function send(Mail $mail, $to)
        mail($to, $mail->subject, $mail->message);

class FileLogger implements Logger
    private $file;

    function __construct($file)
        $this->file = $file;

    function log($message)
        file_put_contents($this->file, $message . "\n", FILE_APPEND);

DI container is the supreme architect which can create individual objects (in the terminology DI called services) and assemble and configure them exactly according to our needs.

Container for our application might look like this:

class Container
    private $logger;
    private $mailer;

    function getLogger()
        if (!$this->logger) {
            $this->logger = new FileLogger('log.txt');
        return $this->logger;

    function getMailer()
        if (!$this->mailer) {
            $this->mailer = new SendMailMailer;
        return $this->mailer;

    function createNewsletterManager()
        return new NewsletterManager($this->getMailer(), $this->getLogger());

The implementation looks like this because:

  • the individual services are created only on demand (lazy loading)
  • doubly called createNewsletterManager will use the same logger and mailer instances

Let's instantiate Container, let it create manager and we can start spamming users with newsletters :-)

$container = new Container;
$manager = $container->createNewsletterManager();

Significant to Dependency Injection is that no class depends on the container. Thus it can be easily replaced with another one. For example with the container generated by Nette DI.

Nette DI

Nette DI is the generator of containers. We instruct it (usually) with configuration files. This is configuration that leads to generate nearly the same class as the class Container above:

    - FileLogger( log.txt )
    - SendMailMailer
    - NewsletterManager

The big advantage is the shortness of configuration.

Nette DI actually generates PHP code of container. Therefore it is extremely fast. Developer can see the code, so he knows exactly what it is doing. He can even trace it.

Usage of Nette DI is very easy. In first, install it using Composer:

composer require nette/di

Save the (above) configuration to the file config.neon and let's create a container:

$loader = new Nette\DI\ContainerLoader(__DIR__ . '/temp');
$class = $loader->load('', function($compiler) {
    $compiler->loadConfig(__DIR__ . '/config.neon');
$container = new $class;

and then use container to create object NewsletterManager and we can send e-mails:

$manager = $container->getByType(NewsletterManager::class);
$manager->distribute(['[email protected]', ...]);

The container will be generated only once and the code is stored in cache (in directory __DIR__ . '/temp'). Therefore the loading of configuration file is placed in the closure in $loader->load(), so it is called only once.

During development it is useful to activate auto-refresh mode which automatically regenerate the container when any class or configuration file is changed. Just in the constructor ContainerLoader append TRUE as the second argument:

$loader = new Nette\DI\ContainerLoader(__DIR__ . '/temp', TRUE);


Services are registered in the DI container and their dependencies are automatically passed.

    manager: NewsletterManager

All dependencies declared in the constructor of this service will be automatically passed. Constructor passing is the preferred way of dependency injection for services.

If we want to pass dependencies by the setter, we can add the setup section to the service definition:

        factory: NewsletterManager
            - setAnotherService

Class of the service:

class NewsletterManager
    private $anotherService;

    public function setAnotherService(AnotherService $service)
        $this->anotherService = $service;


We can also add the inject: yes directive. This directive will enable automatic call of inject* methods and passing dependencies to public variables with @inject annotations:

        factory: FooClass
        inject: yes

Dependency Service1 will be passed by calling the inject* method, dependency Service2 will be assigned to the $service2 variable:

class FooClass
    private $service1;

    // 1) inject* method:

    public function injectService1(Service1 $service)
        $this->service1 = $service1;

    // 2) Assign to the variable with the @inject annotation:

    /** @inject @var Service2 */
    public $service2;

However, this method is not ideal, because the variable must be declared as public and there is no way how you can ensure that the passed object will be of the given type. We also lose the ability to handle the assigned dependency in our code and we violate the principles of encapsulation.


We can use factories generated from an interface. The interface must declare the returning type in the @return annotation of the method. Nette will generate a proper implementation of the interface.

The interface must have exactly one method named create. Our factory interface could be declared in the following way:

interface IBarFactory
     * @return Bar
    public function create();

The create method will instantiate an Bar with the following definition:

class Bar
    private $logger;

    public function __construct(Logger $logger)
        $this->logger = $logger;

The factory will be registered in the config.neon file:

    - IBarFactory

Nette will check if the declared service is an interface. If yes, it will also generate the corresponding implementation of the factory. The definition can be also written in a more verbose form:

        implement: IBarFactory

This full definition allows us to declare additional configuration of the object using the arguments and setup sections, similarly as for all other services.

In our code, we only have to obtain the factory instance and call the create method:

class Foo
    private $barFactory;

    function __construct(IBarFactory $barFactory)
        $this->barFactory = $barFactory;

    function bar()
        $bar = $this->BarFactory->create();


v3.0.0-alpha1 February 02, 2017
v2.4.6 January 15, 2017
v2.4.x-dev January 15, 2017
v2.4.5 December 23, 2016
v2.4.4 October 26, 2016
v2.4.3 September 21, 2016
v2.4.2 July 30, 2016
v2.4.1 July 07, 2016
v2.4.0 June 27, 2016
v2.4.0-beta2 May 20, 2016
See all 44 releases

Project Statistics

SourceRank 20
Dependencies 4
Dependent projects 534
Dependent repositories 1.2K
Total releases 44
Latest release
First release
Stars 79
Forks 40
Watchers 52
Contributors 32
Repo Size: 1.33 MB

Top Contributors See all

David Grudl Filip Procházka David Matějka Jáchym Toušek Jan Tvrdík Jan Škrášek Patrik Votoček Miloslav Hůla Pavel Kouřil Matej Kravjar Petr Morávek Lukáš Unger Michael Moravec sallyx Jakub Vrána Pavel Macháň Martin Zlámal EdaCZ Tomáš Votruba Vojtěch Dobeš

Something wrong with this page? Make a suggestion

Export .ABOUT file for this library

Last synced: 2017-02-02 05:42:48 UTC

Login to resync this project