Dependency injection strategy in a multi-layered application

[razvanbenga89]

Hello everyone!

I was following your series on protocol witnesses and dependency injection and I really love the approach you've taken. It feels really easy to mock clients and test view models with this approach. My question is related on how to apply these concepts in a multi layered system. For instance, I might have a client or usecase that might reference a repository, which, in turn, might reference an apiclient and a datatbaseservice. I'm interested on how I can achieve this and also test the integration between repo, apiclient and dbservice. What came to mind was maybe doing something like this:

public struct Repository {
  var get: () async throws -> Model
  var set: (_ id: String) async throws -> Void
  
  public init(
    get: @escaping () -> Model,
    set: @escaping (_ id: String) async throws -> Void
  ) {
    self.get = get
    self.set = set
  }
}

extension Repository: DependencyKey {
   static var liveValue: Self {
       live(apiClient: .live, dbService: .live)
   }

  static func live(apiClient: ApiClient, dbService: DBService) -> Self {
    . init {
      apiClient.get(....)
    } set: {
      apiClient.set(....)
    } 
  }
}

I was thinking that this way we could use live(apiClient: .test, dbService: .test) inside our tests. Does this look like a good approach? Could we achieve this using the @dependency property wrapper as well? Thanks

[mbrandonw]

Hi @razvanbenga89, your approach of passing dependencies to dependencies can work just fine. It's just a very explicit way of doing dependencies.

If you use the @Dependency property wrapper then you can just use @Dependency(\.apiClient) from within @Dependency(\.repository). Makes this more implicit, but it's still testable.

[razvanbenga89]

Thanks for the reply Brandon. I'm a bit confused on how "you can just use @dependency(.apiClient) from within @dependency(.repository)" would be implemented. Would I end up with nested "withDependencies" calls in order to mock a Repo that's using a mocked apiClient? I'll need to try this out

[arnauddorgans]

@mbrandonw I'm very interested in a answer here, should we use DependencyValues._current if we have an indirect DependencyKey that is only exposed by extension in DependencyValues

[mbrandonw]

Hi @arnauddorgans, sorry I don't understand the question. Really there should never be a reason to access DependencyValues._current.

[arnauddorgans]

What is the best way to resolve a dependency that depends on another dependency? @mbrandonw
Something like:

static var liveValue: Self {
  @Dependency(\.otherDependency) var otherDependency
  return .init(otherDependency: otherDependency)
}

?

[mbrandonw]

Ah I see. No, doing it in that way will resolve the dependency a single time, and it hand it off to the other dependency. This means it will not be overridable later if you want.

It is better to simply use @Dependency in your other dependency:

struct SomeClient {
  var endpoint: @Sendable () -> Int
  static let liveValue = Self {
    @Dependency(\.otherClient) var otherClient
    return otherClient.endpoint()
  }
}