Download the PHP package bhittani/container without Composer

PSR-11 Container

PSR-11 dependency injection container implementation with automatic resolution, service providers, facades and macros. This package does not require any external dependencies.

• Install
• Usage
  • PSR-11 Implementation
  • Container
  • Binding resolution
  • Automatic dependency resolution
  • Interface resolution
  • Callable resolution
  • Custom parameter resolution
  • Factory bindings
  • Shared bindings
  • Delegates
  • Service providers
  • Facades
  • Macros
  • Deferred Service Providers
• Changelog
• Testing
• Contributing
• Security
• Inspiration
• Credits
• License

Install

You may install this package using composer.

Usage

PSR-11 Implementation

This package implements the PSR-11 container interface, hence, you can easily swap any existing implementation with the container provided in this package.

Container

In its simplest form, the container stores key value pairs so that it can be accessed later during your application life cycle.

Binding resolution

Practically, a dependency injection container is more useful by storing class factories/instances so that they are automatically resolved.

The key being used FooDatabase is significant. This key will act as a look-up against any class typehints during resolution attempts of binding parameters (in class constructors, methods, closures, callables, ..., etc).

Still confused? Lets take a closer look at a practical example.

Here, $db is automatically resolved by the container as it is type hinted with the 'FooDatabase' class which the container is aware of.

Automatic dependency resolution

Binding resolution is all handy and dandy but we can do much better and improve on our first iteration.

If we take a closer look at the previous code example, we see that we bind the FooDatabase class explicitly into the container but the Query class is implicitly resolved without any explicit binding.

This means, we should also be able to resolve the FooDatabase class implicitly.

Let's apply our first refactor.

In case you didn't notice, the code line $container->add(FooDatabase::class, new FooDatabase); is completely removed as no binding is required.

How does this work? Lets go behind the scenes for a moment to see what actually happens.

When you call the get method on the container,

1. The container identifies the key as a class that exists.
2. It takes a peek into the constructor parameters and notices a parameter type-hinted as the class FooDatabase.
3. In order to resolve this parameter, it repeats step 1 and 2 using the type-hint as the key.
4. It doesn't see any constructor for the FooDatabase class so it instantiates it and uses that instance to instantiate the Query class.

A binding will take precedence over a new instantiation.

Interface resolution

Wouldn't it be nice if we could implement to an interface so that we could easily swap the underlying implementation?

We have easily swapped the underlying database implementation from FooDatabase to BarDatabase.

Callable resolution

To resolve a callable/closure, we can invoke it directly.

Custom parameter resolution

We can resolve entities that require custom arguments in two ways.

1. Binding the custom argument into the container.
2. Passing explicit arguments.

Explicit arguments will take precedence over bindings.

Factory bindings

Factory bindings allow lazy loading of your instances. Which means that resolution will only occur when it is needed.

This way, you can add as many bindings as you want in your container but only trigger/resolve them when needed. Hence, lazy loaded.

Shared bindings

Shared bindings allow the same instance to be resolved when accessed instead of a new instance every time it is needed.

Delegates

Delegated containers serve as fallback containers that are looked-up for binding resolutions when it can not be found in the container.

Service providers

This package also ships with a service provider container which allows registering of service providers (Think of laravel service providers) in order to have a smooth and easy application development process.

In order to make use of service providers, we will work with a ServiceContainer instead of a simple Container.

Facades

Facades extend the container by assigning custom properties onto the service container. When accessed, it will be resolved out of the service container.

Macros

Macros extend the container by assigning custom methods onto the service container.

Deferred Service Providers

Service providers can be deferred so that services can be lazy loaded.

Using deferred service providers is an efficient way to build up your application as these services will be lazy loaded and act as plug and play while having a minimimum impact on your application performance.

Changelog

Please see CHANGELOG for more information on what has changed.

Testing

Contributing

Please see CONDUCT for details.

Security

If you discover any security related issues, please email [email protected] instead of using the issue tracker.

Inspiration

• league/container
• Laravel

Credits

• Kamal Khan
• All Contributors

License

The MIT License (MIT). Please see the License File for more information.