Advice on where to define dependency injection providers

I am writing an xmlboiler program, especially its core library xmlboiler.core.

I define ExecutionContext in xmlboiler.core.execution_context module.

ExecutionContext is meant to contain a common “environment” suitable for different kinds of tasks.

Currently ExecutionContext contains a logger and a translator of messages:

class ExecutionContext(object):
    def __init__(self, logger, translations):
        """
        :param logger: logger
        :param translations: usually should be gettext.GNUTranslations
        """
        self.logger = logger
        self.translations = translations

Now I want to define some providers using dependency_injector.providers module.

Where (in which module) should I define default factories for loggers, translations, and execution contexts? (Default logger should log to stderr, default translations should respect LANG environment variable.)

The only quite clear thing is that providers should be defined somewhere in xmlboiler.core.* namespace, because it is the namespace for the core library (to be used by several applications).

Should I define providers in xmlboiler.core.execution_context module or in something like xmlboiler.core.execution_context_build, or maybe in something like xmlboiler.core.providers.execution_context?

Note that I think, that it should be in xmlboiler.core.execution_context* rather than in xmlboiler.core.providers*, because in this case the naming rules would not prevent (incorrect) move event to xmlboiler.providers*. Also I don’t want to define the providers in xmlboiler.core.execution_context not to add additional dependencies for this module. However, I am not sure.

The documentation should explicitly address such a question.

[rmk135]

Dependency Injector is designed to be a micro framework, not an application framework. This means that there could be different points of view on how application architecture should look like. However, the goal of “Dependency Injector” is to deliver minimal functional blocks that one can play with for implementing some particular vision.

It does not mean that I do not have my personal vision on using “Dependency Injector for creating applications, but it means more that it’s sort of my own preferences.

Going back to your particular case, I, personally, thinking about next things:

• Module “providers” - is a bad idea.
  • Do not think about having providers module anywhere in your library. The thing is that Provider is a strategy of retrieving an object. Typical providers are Factory, Singleton, Object, Configuration etc… So, basically, you need to subclass providers once you see a certain, not yet covered, way to provide objects. There could be two such situations:
    • 1st: object is created in a very specific way, its initialization requires calling of several instance methods etc…
      • Besides, I, personally, would be creating a special factory method or factory function and use regular Factory provider - Factory(create_object_with_complex_initialization, <injections>).
    • 2nd: object TTL is specific. For example, one is writing multithreaded application. When one uses threads, usage of regular Singleton could lead to “double initialization”, so there is a need to use ThreadSafeSingleton. Another example with multithreading is a ThreadLocalSingleton that creates singleton objects in the scope of each thread. Still, a lot of cases are already covered by dependency_injector.providers module, so there is a big chance to find needed provider there. Also it’s possible to add providers to standard library while there is anything not yet covered, but still common.
• Use containers for grouping providers.
  • Use DeclarativeContainers from dependency_injector.containers to group providers, instead of putting provider instances into modules.
• Put containers on the top of the library.
  • One of the main ideas of “Dependency Injector” is to provide a tool that does not enforce “polluting” the code with dependency injection framework. Many dependency injection frameworks try to “integrate themselves” inside of your code and your code gets dependent on dependency injection framework. “Dependency Injector” is a tool that should be put on the top of the code, not inside of it. So, “code” does not know about existence of “Dependency Injector”, only “Dependency Injector” knows about the code and dependencies. That is what I find a right way for myself.

And, finally, talking about design approach for “xmlboiler” library, I would be doing next things:

• Make most of code components do not know anything about “Dependency Injector”. Link components to each other on maximally top level.
• Create “xmlboiler.containers” module with “dependency_injector.containers.DeclarativeContainer”’s that will group all providers and their injections.

Also, I think you might be interested on taking a look on “Movie lister” example:

• http://python-dependency-injector.ets-labs.org/examples/movie_lister.html
• https://github.com/ets-labs/python-dependency-injector/tree/master/examples/miniapps/movie_lister

I’m not sure if it’s super beneficial for your case, but hope it helps.

[rmk135]

Victor, I’m closing this question cause it looks like that it’s answered. Please, feel free to reopen it, if needed.