Accessing a container (without a framework)

[gsakkis]

I'm evaluating whether dishka or IoC-containers in general can help simplifying my current approach that relies mostly on constructor and (especially) parameter injection. Note I am not using any particular framework (at least any of these listed under dishka integrations), just plain Python with asyncio.

In summary:

• there are a bunch of dependencies that are configured and instantiated at app initialization time.
• these are injected into functions that don't need them directly but forward them to other functions, and so on recursively until several levels deep down the stack where the dependencies are eventually injected to the functions that actually use them.

Now I have wrapped these dependencies into a Provider, created a Container with make_async_container and trying to figure out how to pass it to the functions that need to access it:

• Option 1: Replace all the currently injected dependencies with container, effectively making it a dependency itself. This would be an improvement (replacing N dependencies with 1) but would in principle have the same problem: a bunch of functions accepting a parameter only to forward it to other functions down the stack, without using it themselves.
• Option 2: make the container global/singleton and access it only from the functions that need it. This could also be arguably an improvement (simplifying all the intermediate functions that don't need to be injected with and forward the dependencies) but it's still a global with all the downsides this entails, e.g. require mock.patch for unit testing (which I already use btw but hope to reduce/eliminate).

Is there a better 3rd option?

[Tishka17]

That would be better to have more details about the type of application you develop and its structure, but I'll try to explain some general logic.

Though, you are not using a framework you might have a separation between normal functions and event handlers.

I mean, there is some code that handles interaction with actor (user, queue, requests). This code triggers discovers that new action is requested (found input, event, message, whatever) and calls some handler.
Here we have a boundary. A scope boundary in particular.

At a scope boundary (within event handler or within handler caller) we access a container, enter new scope (usually it is Request) and request your objects.

These objects are created by container, they have dependencies and call other functions. Normally you do not access container here. You just use provided objects and call normal functions. And you do not access container anything from normal functions or classes, only from "event handlers".

So, what am I saying here? You still have a "framework" layer, thought it is not a real framework, just some special part of code. You do not normally use container for framework configuration, but you use it to configure objects called from it.

What can be different here? Ok, your main logic can still trigger an event which should be processed by accessing a container. It is an open question whether you call it directly or using queues. Anyway, you call here the same "framework" layer again. And the entrypoint to that layer is still injected into business logic using DI.

[gsakkis]

Thanks but this sounds rather abstract, I can't translate how it could look like in my case and the examples in the docs are either framework-specific or create and use the container in a single function.

Let me try to illustrate the simplest scenario: all dependencies have (in dishka terminology) APP scope.

1. With parameter injection

def main():
    # creates dependencies and passes them to process_all
    d1 = Dep1()
    d2 = Dep2()
    process_all(..., d1, d2)
    

def process_all(..., d1, d2):
    # doesn't need dependencies directly, just forwards them to process_one()
    ...
    for i some_list:
         result[i] = process_one(i, ..., d1, d2)
    ...

def process_one(..., d1, d2):
    # doesn't need dependencies directly, just forwards them
    ...
    compute1(..., d1)
    ...
    compute2(..., d2)
    
def compute1(..., d1):
   # actually uses d1
    ...
    d1.run(...)
     ...

def compute2(..., d2):
   # actually uses d2
    ...
    d2.run(...)
     ...

2. With global IoC container

class MyProvider(Provider):
    scope = Scope.APP
    d1 = provide(D1)
    d2 = provide(D2)

# global container
container = make_container(MyProvider())

def main():
    # doesn't care about dependencies
    process_all(...)
    

def process_all(...):
    # doesn't care about dependencies
    ...
    for i some_list:
         result[i] = process_one(i, ...)
    ...

def process_one(...):
    # doesn't care about dependencies
    ...
    compute1(...)
    ...
    compute2(...)
    
def compute1(...):
    # gets and uses the dependency/ies it needs
    ...
    d1 = container.get(D1)
    d1.run(...)
    ...

def compute2(...):
    # gets and uses the dependency/ies it needs
    ...
    d2 = container.get(D2)
    d2.run(...)
    ...