Download the PHP package rock-symphony/container without Composer

RockSymphony Service Container

An indie Service Container implementation based on Laravel Container.

Philosophy

• Based on Laravel Container (has most of features of illuminate/container 5.3)
• PSR Container compatibility
• Semantic Versioning
• One dependency (psr/container interface)

Features

• PHP 5.4+, PHP 7.0+
• Automatic dependencies resolution
• Dependency-injecting constructor calls
• Dependency-injecting method calls

Usage

Installation

Use composer.

Basics

Of course you can put services to container (->set()) and get them from it (->get()), as well as check if container has specific service (->has()).

Using abstract interfaces

It's handy to bind services by their abstract interfaces to explicitly declare it's interface on both definition and consumer sides.

Aliases

Sometimes you may also want to bind the same service by different IDs. You can use aliases for that (->alias()):

Binding to a resolver function

You can declare a service by providing a resolver closure function (->bindResolver()). Service container will call that function every time you resolve service.

Deferred resolution service binding

You can defer service initialization until it is requested for the first time. A resolver function will be called just once and its result will be stored to service container.

It works similar to ->bindResolver(), but stores result after first invocation.

Extending a bound service

You can extend/decorate an existing service binding with ->extend() method.

Isolated extension to service container

A use-case: you want to create a new container inheriting services from the existing one. But you don't want to re-define the services again, using the originally defined ones. Also you want to provide more services, without modifying the original container.

Think of it as JavaScript variables scopes: a nested scope inherits all the variables from parent scope. But defining new scope variables won't modify the parent scope. That's it.

Automatic dependency injection

Dependency-injecting construction

You can construct any class instance automatically injecting class-hinted dependencies from service container. It will try to resolve dependencies from container or construct them recursively resolving their dependencies.

Dependency-injecting method call

You can call any callable automatically injecting dependencies from service container. It's primarily intended, but not limited, to call application HTTP controllers.

Note: Service container only resolves class-hinted arguments (i.e. arguments explicitly type-hinted to a class). You should provide required scalar arguments with second argument. It will use default value for options arguments (if you don't specify them).

FAQ

1. Why not use Laravel Container?

   We were using Laravel Container for our project internally. But it's a bad candidate to link it as library as:

   • It doesn't follow SemVer – BC breaks on every minor version bump
   • It has unneeded dependency to flooded illuminate/contracts
   • It's designed to be used as part of Laravel Framework, thus it's almost unusable as-a-library
   • You can use all laravel components only at certain version (i.e. all at 5.3; or all at 5.4; but not mixing)
   • If you want to move forward you are forced to upgrade to latest PHP version (i.e. container 5.4 requires PHP 7.0)
   • Bloated public API: 31 public API methods (vs 10 public methods in this library)
   • Questionable method naming: what's the difference between ->make() and ->build()?

License

This project is licensed under the terms of the MIT license.