Implementing Repository Pattern Flutter

Understanding the Repository Pattern

The repository pattern is a design pattern that mediates between the domain and data mapping layers, acting as an in-memory domain object collection. In Flutter applications, repositories serve as a single source of truth for data access, abstracting the underlying data sources--whether REST APIs, local databases, or device-specific APIs--behind a consistent interface, as demonstrated in Code With Andrea's comprehensive Flutter architecture guide.

Key Benefits of the Repository Pattern

• Abstraction: Isolates domain logic from data source implementation details
• Testability: Enables easy mocking of data layers during unit testing
• Maintainability: Centralizes data access logic in one location
• Flexibility: Allows seamless switching between different data sources
• Separation of Concerns: Keeps business logic independent of data fetching details

When to Use the Repository Pattern

The repository pattern becomes valuable when your application needs to:

• Access multiple data sources (API, database, cache)
• Support different implementations for the same data operations
• Enable comprehensive unit testing without network dependencies
• Maintain clean separation between UI and data access logic
• Handle complex data transformations consistently

This architectural approach is particularly valuable when building cross-platform mobile applications that need to work seamlessly across iOS and Android while maintaining consistent data handling patterns. For teams also working on web applications, the same repository patterns can be applied across platforms to maximize code reuse and maintainability.

Repository Pattern Architecture in Flutter

According to Flutter's official app architecture guide, repositories belong to the data layer alongside services. This placement ensures that repositories handle data retrieval, storage, and transformation while keeping higher layers focused on business logic and presentation.

Repository in Clean Architecture

In Clean Architecture, repositories typically:

1. Domain Layer: Defines interfaces (abstract classes) that specify what operations are available
2. Data Layer: Provides concrete implementations that handle actual data operations
3. Presentation Layer: Depends on abstractions, not concrete implementations

This dependency inversion allows the presentation layer to remain unaware of whether data comes from a remote API, local database, or mocked source. By following these principles, your Flutter codebase becomes more maintainable and easier to test across different scenarios. Teams implementing AI-powered features in their mobile applications will find this architecture particularly valuable for abstracting complex machine learning API integrations.

Implementation Strategies

Approach 1: Using Abstract Classes

The abstract class approach defines a contract (interface) that specifies methods for data operations. Concrete implementations then fulfill this contract, providing flexibility to swap implementations as discussed in Code With Andrea's analysis of abstract vs concrete approaches:

// Abstract interface defining the contract
abstract class UserRepository {
 Future<User> getUser(int id);
 Future<List<User>> getUsers();
 Future<User> createUser(User user);
 Future<User> updateUser(User user);
 Future<void> deleteUser(int id);
}

// Concrete implementation for API
class ApiUserRepository implements UserRepository {
 final ApiClient _client;
 ApiUserRepository(this._client);

 @override
 Future<User> getUser(int id) async {
 final response = await _client.get('/users/$id');
 return User.fromJson(response.data);
 }
}

Approach 2: Using Concrete Classes

Some developers prefer concrete classes when only one implementation is needed, reducing boilerplate while maintaining clear organization, as Code With Andrea explains in their comparison of approaches:

class UserRepository {
 final ApiClient _client;
 final CacheManager _cache;

 UserRepository(this._client, this._cache);

 Future<User> getUser(int id) async {
 final cached = await _cache.get('user_$id');
 if (cached != null) return User.fromJson(cached);

 final response = await _client.get('/users/$id');
 final user = User.fromJson(response.data);
 await _cache.set('user_$id', response.data);

 return user;
 }
}

Both approaches have their merits--choose based on your project's complexity and testing requirements. For applications requiring local data persistence, concrete classes with built-in caching often provide the simplest path forward.

Practical Implementation Example

Step 1: Define Domain Models

class Post {
 final int id;
 final String title;
 final String body;
 final int userId;

 Post({
 required this.id,
 required this.title,
 required this.body,
 required this.userId,
 });

 factory Post.fromJson(Map<String, dynamic> json) {
 return Post(
 id: json['id'],
 title: json['title'],
 body: json['body'],
 userId: json['userId'],
 );
 }

 Map<String, dynamic> toJson() => {
 'id': id,
 'title': title,
 'body': body,
 'userId': userId,
 };
}

Step 2: Create Repository Interface

abstract class PostRepository {
 Future<List<Post>> getPosts();
 Future<Post> getPost(int id);
 Future<Post> createPost(Post post);
 Future<Post> updatePost(Post post);
 Future<void> deletePost(int id);
 Future<List<Post>> getPostsByUser(int userId);
}

Step 3: Implement Concrete Repository

class HttpPostRepository implements PostRepository {
 final http.Client _client;
 final String baseUrl;

 HttpPostRepository(this._client, {required this.baseUrl});

 @override
 Future<List<Post>> getPosts() async {
 final response = await _client.get(Uri.parse('$baseUrl/posts'));

 if (response.statusCode == 200) {
 final List<dynamic> data = json.decode(response.body);
 return data.map((json) => Post.fromJson(json)).toList();
 } else {
 throw ServerException('Failed to load posts: ${response.statusCode}');
 }
 }

 @override
 Future<Post> getPost(int id) async {
 final response = await _client.get(Uri.parse('$baseUrl/posts/$id'));

 if (response.statusCode == 200) {
 return Post.fromJson(json.decode(response.body));
 } else if (response.statusCode == 404) {
 throw PostNotFoundException('Post not found: $id');
 } else {
 throw ServerException('Failed to load post: ${response.statusCode}');
 }
 }
}

This implementation follows patterns documented by LogRocket for production-ready Flutter applications.

Common Pitfalls to Avoid

1. Repository God Object: Avoid creating a single repository that handles everything--split by domain entity instead
2. Leaking Implementation Details: Don't expose API-specific types in repository interfaces
3. Ignoring Offline Scenarios: Handle network failures gracefully with proper error handling
4. Skipping Tests: Always write tests for repository implementations
5. Over-Engineering: Don't create abstractions before they're needed

Following these guidelines from experienced Flutter developers will help you avoid common mistakes that lead to unmaintainable codebases. For teams building multi-step workflows in their applications, our guide on creating multi-step forms with Flutter Stepper demonstrates how to apply clean architecture principles to user interface components.

Testing Repositories

Testing repositories requires mocking the underlying HTTP client or database, as demonstrated in Code With Andrea's testing guide:

import 'package:flutter_test/flutter_test.dart';
import 'package:mocktail/mocktail.dart';
import 'package:http/http.dart' as http;

class MockHttpClient extends Mock implements http.Client {}

void main() {
 late HttpPostRepository repository;
 late MockHttpClient mockClient;

 setUp(() {
 mockClient = MockHttpClient();
 repository = HttpPostRepository(
 mockClient, 
 baseUrl: 'https://jsonplaceholder.typicode.com'
 );
 });

 test('returns list of posts on successful response', () async {
 final response = http.Response(
 jsonEncode([
 {'id': 1, 'title': 'Test Post', 'body': 'Body', 'userId': 1}
 ]),
 200,
 );

 when(() => mockClient.get(any())).thenAnswer((_) async => response);

 final posts = await repository.getPosts();

 expect(posts, hasLength(1));
 expect(posts.first.title, 'Test Post');
 });

 test('throws ServerException on non-200 response', () async {
 final response = http.Response('Server Error', 500);
 when(() => mockClient.get(any())).thenAnswer((_) async => response);

 expect(
 () => repository.getPosts(),
 throwsA(isA<ServerException>()),
 );
 });
}

By testing your repositories in isolation, you can ensure your data layer is robust without depending on external services.

Dependency Injection for Repositories

Using get_it

import 'package:get_it/get_it.dart';

GetIt getIt = GetIt.instance;

void setupDependencies() {
 getIt.registerLazySingleton<http.Client>(() => http.Client());

 getIt.registerLazySingleton<PostRepository>(
 () => HttpPostRepository(
 getIt<http.Client>(),
 baseUrl: 'https://jsonplaceholder.typicode.com',
 ),
 );
}

Using Riverpod

import 'package:flutter_riverpod/flutter_riverpod.dart';

final postRepositoryProvider = Provider<PostRepository>((ref) {
 final httpClient = ref.watch(httpClientProvider);
 return HttpPostRepository(
 httpClient,
 baseUrl: 'https://jsonplaceholder.typicode.com',
 );
});

final httpClientProvider = Provider<http.Client>((ref) {
 return http.Client();
});

Dependency injection is essential for making your repositories testable and your application flexible, as Code With Andrea explains in their DI guide.

Advanced Topics

Caching Strategies

Implement multi-level caching for optimal performance, as recommended in LogRocket's caching strategies:

class CachedPostRepository implements PostRepository {
 final PostRepository _remoteRepository;
 final CacheManager _cache;

 CachedPostRepository(this._remoteRepository, this._cache);

 @override
 Future<List<Post>> getPosts() async {
 final cached = await _cache.get('posts');
 if (cached != null) {
 final posts = (cached as List).map((e) => Post.fromJson(e)).toList();
 return posts;
 }

 final posts = await _remoteRepository.getPosts();
 await _cache.set('posts', posts.map((p) => p.toJson()).toList());

 return posts;
 }
}

Repository with Retry Logic

class ResilientPostRepository implements PostRepository {
 final PostRepository _delegate;
 final int maxRetries;

 ResilientPostRepository(this._delegate, {this.maxRetries = 3});

 @override
 Future<List<Post>> getPosts() async {
 int attempts = 0;
 Exception? lastError;

 while (attempts < maxRetries) {
 try {
 return await _delegate.getPosts();
 } catch (e) {
 lastError = e;
 attempts++;
 if (attempts < maxRetries) {
 await Future.delayed(Duration(milliseconds: 100 * attempts));
 }
 }
 }

 throw lastError ?? Exception('Max retries exceeded');
 }
}

These advanced patterns help you build resilient Flutter applications that handle real-world network conditions gracefully.

Conclusion

The repository pattern is a powerful architectural pattern that enables clean separation between data access and business logic in Flutter applications. By implementing repositories, you gain flexibility in testing, maintainability of code, and the ability to switch data sources without affecting the rest of your application.

Whether you choose abstract classes with multiple implementations or concrete classes with internal variation, the key is consistency and clear organization. Combine repositories with proper dependency injection and state management for a robust, scalable architecture that will serve your cross-platform mobile applications well.

For teams building complex mobile applications, investing in clean architecture patterns like the repository pattern pays dividends in reduced technical debt and easier feature development over time. Our mobile development services team can help you implement these patterns in your production applications.

Sources

1. LogRocket: Implementing Repository Pattern Flutter - Core concepts, step-by-step implementation, and code examples
2. Code With Andrea: Flutter Repository Pattern - Architecture patterns, testing strategies, and abstract vs concrete class trade-offs
3. Flutter Documentation: App Architecture Guide - Official Flutter architecture recommendations and repository placement