Download the PHP package rkr/php-ioc-contract without Composer
On this page you can find all versions of the php package rkr/php-ioc-contract. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package php-ioc-contract
php-ioc-contract
A contract for ioc-containers
Do not use this library as long it is not 1.0.
Abstract
This project provides a documentation for the api and the behavior of three different concerns:
- InstanceContainer - a container that returns instances associated with keys.
- ObjectFactory - an abstract factory to create new object-instances from. E.g. used in factories to create new entities.
- MethodInvoker - invoke a method, function or closure. E.g. used in dispatchers to start a subprogram.
Motivation
Lets say you wan't to build a rule-based service-dispatcher (or an http-router like silex), that invoke registered closures only if a certain condition is met:
It would be fun, if I already had the domain-objects I need to work with. This would look like this:
$serviceDispatcher should not be aware of a BusinessObject directly. But the ServiceDispatcher may know of an generic way to call a callable (like a closure) and resolve those parameters by a component outside of ServiceDispatcher's scope. How this is archived is not a concern of the ServiceDispatcher. It just happens somehow.
The goal could be archived with an Dependency-Injection-Container. There are different ioc-containers out there with quite different interfaces (my current favorite is PHP-DI). So we need a common interface to pass an instance around which is aware of how to instantiate our domain-objects so that we could directly use them:
Now the run-method in the ServiceDispatcher-implementation could simply look like this:
InstanceContainer
A InstanceContainer is mostly useful when in subjection to a di-container only a single instance of an object should be used. This is slightly different to the use of a singleton-pattern since you can have multiple di-containers with different configurations that may inject different implementations for the provided interfaces. For implementation details, look at the phpdoc-blocks.
ObjectFactory
A ObjectFactory is mostly useful in common factories to create entities. For implementation details, look at the phpdoc-blocks.
MethodInvoker
Invokes a callable method, function or closure and resolve the required parameters automatically of not already
provided. For implementation details, look at the phpdoc-blocks.
