View Categories

How do you implement Dependency Injection (DI) in Dart?

Parthiban Kannan
Updated on December 6, 2025

1 min read

Dependency Injection (DI) in Dart is all about decoupling object creation from object usage — so that classes depend on abstractions rather than concrete implementations. It helps in writing cleaner, testable, and more maintainable code.

In one of my Flutter projects, I implemented DI to manage services like API clients, local storage, and authentication. Instead of creating instances directly inside widgets or classes, I injected them through constructors or a dependency injection framework like get_it.

For example, using constructor injection, I might define a repository class like this:

📄
filename.dart 
class UserRepository {
  final ApiService apiService;

  UserRepository(this.apiService);

  Future fetchUser() => apiService.getUser();
}

Then, in the main setup, I can pass dependencies explicitly:

📄
filename.dart 
void main() {
  final apiService = ApiService();
  final userRepository = UserRepository(apiService);

  runApp(MyApp(userRepository: userRepository));
}

This way, UserRepository doesn’t need to know how ApiService is created — it just uses it. That made testing much easier since I could inject a mock or fake API service during unit tests instead of calling real APIs.

For larger apps, I used the GetIt package — which is a lightweight service locator. Here’s how I usually set it up:

📄
filename.dart 
final getIt = GetIt.instance;

void setup() {
  getIt.registerLazySingleton(() => ApiService());
  getIt.registerFactory(() => UserRepository(getIt()));
}

Then I can simply retrieve dependencies anywhere in the app:

📄
filename.dart 
final userRepo = getIt();

One challenge I faced was managing the lifecycle of dependencies — especially when mixing singleton and factory registrations. At times, I accidentally used a singleton where I needed a fresh instance, which led to unexpected data persistence. I solved this by clearly documenting what should be singleton (like services) and what should be factory (like view models).

The main limitation with manual DI or service locators is boilerplate — it can get repetitive in larger projects. As an alternative, frameworks like Riverpod or Provider offer declarative DI with reactive state management, which I’ve also used when building scalable Flutter apps.

Scroll to Top