2015-06-10 12:00:43 +03:00
|
|
|
Singleton providers
|
|
|
|
-------------------
|
|
|
|
|
2015-11-30 00:30:48 +03:00
|
|
|
.. currentmodule:: dependency_injector.providers
|
2015-11-23 15:43:11 +03:00
|
|
|
|
|
|
|
:py:class:`Singleton` provider creates new instance of specified class on
|
|
|
|
first call and returns same instance on every next call.
|
2015-06-10 12:00:43 +03:00
|
|
|
|
2015-06-24 12:29:58 +03:00
|
|
|
Example:
|
|
|
|
|
2015-07-25 00:51:14 +03:00
|
|
|
.. image:: /images/providers/singleton.png
|
2015-06-26 10:21:23 +03:00
|
|
|
:width: 80%
|
|
|
|
:align: center
|
2015-06-24 12:29:58 +03:00
|
|
|
|
2015-08-03 15:56:40 +03:00
|
|
|
.. literalinclude:: ../../examples/providers/singleton.py
|
|
|
|
:language: python
|
2016-04-11 10:43:02 +03:00
|
|
|
:linenos:
|
2015-06-10 12:00:43 +03:00
|
|
|
|
2016-06-08 17:46:40 +03:00
|
|
|
Singleton providers resetting
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
Created and memorized by :py:class:`Singleton` instance can be reset. Reset of
|
|
|
|
:py:class:`Singleton`'s memorized instance is done by clearing reference to
|
2016-11-11 18:05:25 +03:00
|
|
|
it. Further lifecycle of memorized instance is out of :py:class:`Singleton`
|
2020-06-14 05:24:32 +03:00
|
|
|
provider's control and depends on garbage collection strategy.
|
2016-06-08 17:46:40 +03:00
|
|
|
|
|
|
|
Example:
|
|
|
|
|
2020-06-14 05:24:32 +03:00
|
|
|
.. literalinclude:: ../../examples/providers/singleton_resetting.py
|
2016-06-08 17:46:40 +03:00
|
|
|
:language: python
|
|
|
|
:linenos:
|
|
|
|
|
2015-06-10 12:00:43 +03:00
|
|
|
Singleton providers and injections
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
2016-11-11 18:05:25 +03:00
|
|
|
:py:class:`Singleton` provider has same interface as :py:class:`Factory`
|
|
|
|
provider, so, all of the rules about injections are the same, as for
|
|
|
|
:py:class:`Factory` provider.
|
2015-06-24 12:29:58 +03:00
|
|
|
|
2015-06-10 12:00:43 +03:00
|
|
|
.. note::
|
|
|
|
|
2015-11-23 15:43:11 +03:00
|
|
|
Due that :py:class:`Singleton` provider creates specified class instance
|
|
|
|
only on the first call, all injections are done once, during the first
|
2016-11-11 18:05:25 +03:00
|
|
|
call. Every next call, while instance has been already created
|
2015-11-23 15:43:11 +03:00
|
|
|
and memorized, no injections are done, :py:class:`Singleton` provider just
|
|
|
|
returns memorized earlier instance.
|
2015-06-10 12:00:43 +03:00
|
|
|
|
|
|
|
This may cause some problems, for example, in case of trying to bind
|
2015-11-23 15:43:11 +03:00
|
|
|
:py:class:`Factory` provider with :py:class:`Singleton` provider (provided
|
|
|
|
by dependent :py:class:`Factory` instance will be injected only once,
|
|
|
|
during the first call). Be aware that such behaviour was made with opened
|
|
|
|
eyes and is not a bug.
|
2015-06-10 12:00:43 +03:00
|
|
|
|
2015-12-28 18:25:25 +03:00
|
|
|
By the way, in such case, :py:class:`Delegate` or
|
|
|
|
:py:class:`DelegatedSingleton` provider can be useful
|
|
|
|
. It makes possible to inject providers *as is*. Please check out
|
|
|
|
`Singleton providers delegation`_ section.
|
2015-06-10 12:00:43 +03:00
|
|
|
|
2015-07-20 19:31:31 +03:00
|
|
|
Singleton providers delegation
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
2015-11-23 15:43:11 +03:00
|
|
|
:py:class:`Singleton` provider could be delegated to any other provider via
|
2016-06-08 17:46:40 +03:00
|
|
|
any kind of injection.
|
2015-12-28 18:25:25 +03:00
|
|
|
|
2016-06-08 17:46:40 +03:00
|
|
|
Delegation of :py:class:`Singleton` providers is the same as
|
|
|
|
:py:class:`Factory` providers delegation, please follow
|
|
|
|
:ref:`factory_providers_delegation` section for examples (with exception
|
2017-04-07 01:00:52 +03:00
|
|
|
of using :py:class:`DelegatedSingleton` instead of
|
2016-06-08 17:46:40 +03:00
|
|
|
:py:class:`DelegatedFactory`).
|
2015-12-28 18:25:25 +03:00
|
|
|
|
2015-12-13 15:22:59 +03:00
|
|
|
Singleton providers specialization
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
:py:class:`Singleton` provider could be specialized for any kind of needs via
|
|
|
|
declaring its subclasses.
|
|
|
|
|
2016-06-08 17:46:40 +03:00
|
|
|
Specialization of :py:class:`Singleton` providers is the same as
|
|
|
|
:py:class:`Factory` providers specialization, please follow
|
|
|
|
:ref:`factory_providers_specialization` section for examples.
|
2016-08-19 00:56:41 +03:00
|
|
|
|
2017-04-07 01:00:52 +03:00
|
|
|
Abstract singleton providers
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
:py:class:`AbstractSingleton` provider is a :py:class:`Singleton` provider that
|
|
|
|
must be explicitly overridden before calling.
|
|
|
|
|
|
|
|
Behaviour of :py:class:`AbstractSingleton` providers is the same as of
|
|
|
|
:py:class:`AbstractFactory`, please follow :ref:`abstract_factory_providers`
|
|
|
|
section for examples (with exception of using :py:class:`AbstractSingleton`
|
|
|
|
provider instead of :py:class:`AbstractFactory`).
|
|
|
|
|
2016-08-19 00:56:41 +03:00
|
|
|
Singleton providers and multi-threading
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
2016-11-11 18:05:25 +03:00
|
|
|
:py:class:`Singleton` provider is NOT thread-safe and should be used in
|
|
|
|
multi-threading applications with manually controlled locking.
|
|
|
|
|
|
|
|
:py:class:`ThreadSafeSingleton` is a thread-safe version of
|
|
|
|
:py:class:`Singleton` and could be used in multi-threading applications
|
|
|
|
without any additional locking.
|
2016-08-19 00:56:41 +03:00
|
|
|
|
|
|
|
Also there could be a need to use thread-scoped singletons and there is a
|
|
|
|
special provider for such case - :py:class:`ThreadLocalSingleton`.
|
|
|
|
:py:class:`ThreadLocalSingleton` provider creates instance once for each
|
|
|
|
thread and returns it on every call.
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
.. literalinclude:: ../../examples/providers/singleton_thread_locals.py
|
|
|
|
:language: python
|
|
|
|
:linenos:
|
2017-02-28 23:07:12 +03:00
|
|
|
|
|
|
|
|
|
|
|
.. disqus::
|