Best Practices for Factory Container Usage in Large-Scale Applications

[sophiekopaliani]

Hello,

I'm working on migrating a large-scale monolithic iOS application from Resolver to Factory for dependency injection. We want to implement service locator kind of functionality, so the general classes are agnostic to DI Library used.



I wanted to know what is the best practice then it comes to using custom containers in a large application.







Our current proposed approach is apart from shared container to have Flow-Level Containers: Each major flow (feature) has its own container. It contains low-specific repositories, controllers, coordinators etc.
 We are planning to have service locators for individual view models (where some objects are resolved either from flow or shared containers).

We were thinking if we should create even more granular containers at the scene level?
Open for all suggestions, 
If you need more information please let me know.

[psi-gh]

Same question here. I really like the idea of Factory, and in my opinion, it’s the cleanest DI library available.
My confusion is: I don’t see a good way to write an Adapter for Factory, as I did before with Swinject. In the previous case, it was a simple Adapter with register and resolve, and the modules remained unaware of the DI library.

However, with Factory, it seems I would need to proxy or wrap a lot of functionality in the adapter, including the Factory<T> type for registration through properties, all property wrappers (e.g., Injected, LazyInjected +3-4 more), AutoRegister, as well as register and reset for testing. Such an adapter would essentially duplicate the Factory API, defeating its core purpose of being agnostic to implementation details.

If I decide to replace Factory with another framework in four years, what are the chances that the new framework will have the exact same API?

So I kinda stuck here because I have a huge app with 30+ modules in it :)
Currently, it seems like tradeoff: you get a very nice, clean & almost magic way to inject dependencies for the price of tightly coupling all the codebase to particular implementation.

[psi-gh]

Follow-up thought: From the same perspective, my Swinject Adapter also doesn’t fully serve its purpose because it’s too simple and cannot be adapted to Factory or most other new DI libraries.

[hmlongco]

So... there are quite a few libraries out there that basically do @Injected(\.service) var service, the property wrapper isn't that hard to write, and in fact most of them have copied Factory and already have them built in.

Second, if you're doing var myService = Container.shared.service(), the usage at the call site just looks like a normal function call. An adapted definition might look like:

    func myService() -> MyServiceType {
        resolve(MyServiceType.*)
    }

Which in turn means that, yes, you'd have to have to rewrite the factories. We did the same in an app the switched from Swinject and, while boring, got most of it done in a day.

Third, it's possible to mask Factory's definitions by doing something similar like.

    func myService() -> MyServiceType {
        self { MyService() }()
    }

Then again, you lose access to the ability to override the service type.

Also seen:

    var myService: MyServiceType { _myService() }
    var _myService: Factory<MyServiceType> { self { MyService() } }

More boilerplate, but masks Factory to most call sites.

I've also seen these little gems added to a Container.

func resolve<T>(_ path: KeyPath<ResolvingContainer, Factory<T>>) -> T {
    self[keyPath: path]()
}

func register<T>(_ path: KeyPath<ResolvingContainer, Factory<T>>, _ factory: @escaping @Sendable () -> T) {
    self[keyPath: path].register(factory: factory)
}

Allowing...

Container.shared.register(\.service) { MockService() }
...
var service = Container.shared.resolve(\.service)

These are starting to grow on me, actually. Might add them to the library.

But yes, all of these are more complex than a simple register/resolve interface. That's kind of the price one pays for the compile-time safety aspects.

[hmlongco]

@psi-gh So what did you think of

func resolve<T>(_ path: KeyPath<ResolvingContainer, Factory<T>>) -> T {
    self[keyPath: path]()
}

func register<T>(_ path: KeyPath<ResolvingContainer, Factory<T>>, _ factory: @escaping @Sendable () -> T) {
    self[keyPath: path].register(factory: factory)
}

Allowing...

Container.shared.register(\.service) { MockService() }
...
var service = Container.shared.resolve(\.service)

Thinking of adding them... and they're definitely easier to stub.

[psi-gh]

Hi Michael, thank you for responding!
It sounds very interesting. I see - it adds a more “traditional” way to register and resolve.
I assume that in case of AutoRegistering the autoRegister() method, I could use func factory<T>(_ type: T.Type) -> Factory<T>? and do something like this:

  func autoRegister {
        container.factory(AccountLoaderProtocol.self).register { AccountLoader() }
        ...
    }

The remaining issue is that in modules where we use proxies for register and resolve (with func resolve and func register), we lose the ability to use the nice and clean @injected (and its options). So I guess we can either stub it too or just use resolve and pass the parameters manually in the initializers.
I’m not sure what the best approach is yet—need to think it through a bit more.

I’m also thinking about a project where some modules are supposed to be shared outside, so they better not bring dependencies with them. In this case, a mixed approach can be applied - shared modules use register/resolve stubs and don’t know about the DI lib, and the rest of the app just uses Factory at its fullmost.

[hmlongco]

No. Those are key paths to Factorys. You still need the definition to exist. In autoregister or in tests you'd do:

Container.shared.register(\.service) { ExternalService() }

It just hides most of Factory from the call sites.

And you could still use @injected, if you're doing so now.