Dependency Injection/Inversion, DDD, and Clean Code with Riverpod

[matthew-nm]

I'm having a conceptual issue I can't seem to get myself out of. I found this discussion that I believe relates but it did not resolve in a way that helps me move forward: (#450).

I'm attempting to learn app development and a deluge of clean coding concepts all at once. I am writing a practice app with the 4 DDD layers, Presentation, Application, Domain, and Infrastructure. I am using TDD to write tests to lead me and mocking as needed.

For the sign-in/auth feature, I've written the entities, states, and the interface for an auth facade (IAuthFacade). I do not have a concrete implementation of IAuthFacade, which means I cannot write a Provider for it since Providers need to serve concrete implementations.

I am now writing a NotifierProvider for the app's Sign-in page in the Application layer, but I do not know how to inject the interface without providing a concrete implementation. I would rather not write an implementation in the Infrastructure layer just so I can mock it all away in the Application tests.

To get around this, I do something like this,

@riverpod
class SignInNotifier extends _$SignInNotifier {
  late final IAuthFacade _authFacade;

  @override
  SignInState build() => SignInState.initial();

  void injectDependencies(IAuthFacade authFacade) {
    _authFacade = authFacade;
  }

  // methods...
}

so that in my testing suite I can mock and inject the interface as needed.

This works well enough for isolated development, but now I have to deal with setting the dependency when the code actually runs and this feels wrong. Obviously using a registering system instead like get_it would make this better, but that is an anti-pattern as described in the discussion linked at top.

So how does Riverpod's Provider system fit in here? I can't define a provider without a concrete implementation (unless I'm missing something), and I don't see the need to have an implementation when don't need it (I'm writing the Notifier Provider in isolation, the interface is defined, and I mock the implementation outputs as needed). I believe it also breaks the dependency inversion principle.

To use a Provider I believe I'll need to turn my whole coding process somewhat upside-down and write a half-way implementation of IAuthFacade just so I can provide it, then mock it. But this can't be right either.

[snapsl]

Usually, DI in riverpod works like any other provider. Just to give an option.

@riverpod
IAuthFacade authFacade(AuthFacadeRef ref) => throw UnimplementedError();

// In "main" or where required
ProviderScope(
overrides: [authFacadeProvider.overrideWithValue(concreteAuthImpl)]
child: ...
)

For testing replace concreteAuthImpl with mock.
But maybe I am missing something.

[matthew-nm]

Ah ha! The throw UnimplementedError() was the key. I didn't realize you could throw instead of providing a concrete implementation (but that makes sense, otherwise what would the UnimplementedError be for?).

With the Provider defined as such, I can now do this in my Notifier Provider,

@riverpod
class SignInNotifier extends _$SignInNotifier {
  late final IAuthFacade _authFacade;

  @override
  SignInState build() {
    _authFacade = ref.watch(authFacadeProvider);
    return SignInState.initial();
  }

  // methods...
}

and I'm golden!

And of course I'll override the concrete implementation of the IAuthFacade into its Provider in main.dart's ProviderScope when it comes time to tie it all together.

Much thanks!

---

For anyone who cares, I also do this in my testing script,

// up top
@riverpod
class DebugSignInNotifier extends SignInNotifier {
  @override
  SignInState build() => super.build();

  void setDebugState(SignInState debugState) {
    state = debugState;
  }
}

// in main()
 setUp(() {
    sut = debugSignInNotifierProvider;
    mockAuthFacade = MockAuthFacade();
    container = createContainer(
      overrides: [authFacadeProvider.overrideWithValue(mockAuthFacade)]
    );
  });

to make setting the starting state of the Notifier Provider easier for individual tests.

[snapsl]

Great sum up!

[gdurandrexel]

Also, you cannot inject dependencies into private fields or via the constructor as you would do with DI frameworks on other platforms such as .NET or Java. You have to pull the dependency from the container via your ref whenever you need it, usually with ref.watch in build() or ref.read in the other methods.

What you can do is create the SignInNotifier class with its dependencies passed in the constructor, and create a provider of SignInNotifier that fetches the dependencies from the container and returns an instance of SignInNotifier.
Basically you do manually what other frameworks do via reflection or code generation.

class SignInNotifier {
  final IAuthFacade _authFacade;

  SignInNotifier(this._authFacade);
 
  // methods...
}

@riverpod
SignInNotifier signInNotifier(SignInNotifierRef ref) {
  final authFacade = ref.watch(authFacadeProvider);

  return SignInNotifier(authFacade);
}

[snapsl]

Like it 👍
Even though, why is this wrapper needed here? I am not from .NET. Now the notifier has to define its methods. Should not the interface define the methods?

[gdurandrexel]

Hum, my answer does not answer your question actually.

If I understand well, SignInNotifier is the "controller" for the SignIn page, i.e. it provides the model for the page and the methods to act on it.
In this case using the technique I described is not appropriate, and the controller will probably have to depend on riverpod and pull it's dependencies directly in its implementation.

What I described in my previous answer works only for the lower layers.