Repository pattern in Flutter - Deep Dive

Overview - Repository pattern

What is it?

The Repository pattern is a way to organize how your app gets and saves data. It acts like a middleman between your app's logic and where the data lives, such as a database or a web service. This pattern helps keep your code clean and easy to change by hiding the details of data access. It makes your app easier to test and maintain.

Why it matters

Without the Repository pattern, your app's code would be tangled with details about how data is fetched or saved. This makes it hard to fix bugs, add new features, or switch data sources. Using this pattern means you can change where your data comes from without rewriting your whole app. It saves time and reduces mistakes, especially as apps grow bigger.

Where it fits

Before learning the Repository pattern, you should understand basic Flutter app structure and how to fetch data asynchronously. After this, you can learn about state management and dependency injection, which often work together with repositories to build scalable apps.

Mental Model

Core Idea

A repository is a simple interface that hides the details of data storage and retrieval, letting your app focus on what to do with data, not how to get it.

Think of it like...

Think of a repository like a library's front desk. You ask the desk for a book, and they get it for you from the shelves or another branch. You don't need to know where the book is or how they find it, just that you get the book when you ask.

App UI/Logic
   │
   ▼
┌───────────────┐
│ Repository    │  <-- Interface hiding data details
└───────────────┘
   │          │
   ▼          ▼
Database    Web API
(or other sources)

Build-Up - 7 Steps

1

Foundation

Understanding data sources in apps

Concept: Apps get data from places like databases or web services, but these sources work differently.

In Flutter, you might fetch data from a local database using packages like sqflite, or from the internet using HTTP requests. Each source has its own way to read and write data, which can make your app code complex if mixed together.

Result

You see that data access code can be scattered and hard to manage.

Knowing that data comes from different places helps you see why hiding these details is useful.

2

Foundation

Separating data logic from UI code

Concept: Keeping data fetching code separate from UI code makes apps easier to read and fix.

Instead of calling HTTP or database code directly inside your widgets, you create separate classes or functions that handle data. This way, your UI just asks for data without worrying about how it's fetched.

Result

Your UI code becomes cleaner and focused only on showing data.

Separating concerns reduces bugs and makes your app easier to update.

3

Intermediate

Introducing the Repository pattern

🤔Before reading on: do you think a repository directly fetches data or just defines how to get it? Commit to your answer.

Concept: A repository defines a simple interface for data operations and hides the details of where data comes from.

You create a repository class with methods like getItems() or saveItem(). Inside, it decides whether to get data from a database, a web API, or cache. The rest of your app only talks to the repository, not the data sources.

Result

Your app code calls repository methods and stays the same even if data sources change.

Understanding that repositories act as a single point of contact for data simplifies app design and future changes.

4

Intermediate

Implementing repository interfaces in Flutter

🤔Before reading on: do you think repository classes should depend on concrete data sources or abstract them? Commit to your answer.

Concept: Repositories use interfaces or abstract classes to define data operations, allowing different implementations for testing or changing data sources.

Define an abstract repository class with method signatures. Then create concrete classes that implement these methods using specific data sources. This lets you swap implementations easily, for example, using a fake repository for tests.

Result

Your app can switch data sources without changing UI or business logic code.

Knowing how to use abstraction in repositories enables flexible and testable app architecture.

5

Intermediate

Combining repositories with state management

Concept: Repositories provide data to state management solutions, which then update the UI.

In Flutter, you might use providers, Riverpod, or Bloc to manage app state. These state managers call repository methods to fetch or save data. When data changes, they notify the UI to rebuild with new information.

Result

Your app updates smoothly when data changes, keeping UI and data logic cleanly separated.

Understanding this flow helps you build apps that are easier to maintain and scale.

6

Advanced

Handling multiple data sources in repositories

🤔Before reading on: do you think a repository should fetch data from all sources every time or choose smartly? Commit to your answer.

Concept: Repositories can combine data from cache, database, and network to optimize performance and reliability.

A repository might first check a local cache or database for data. If not found or outdated, it fetches fresh data from the network and updates the local storage. This strategy improves speed and offline support.

Result

Your app feels faster and works even without internet connection.

Knowing how to coordinate multiple data sources inside a repository improves user experience and app robustness.

7

Expert

Advanced repository patterns and dependency injection

🤔Before reading on: do you think repositories should create their own data sources or receive them from outside? Commit to your answer.

Concept: Using dependency injection to provide data sources to repositories increases modularity and testability.

Instead of repositories creating database or API clients themselves, these dependencies are passed in from outside, often using a dependency injection framework. This allows easy swapping of implementations and better control over app components.

Result

Your app architecture becomes more flexible and easier to test with mock data sources.

Understanding dependency injection with repositories is key to building professional, maintainable Flutter apps.

Under the Hood

At runtime, the repository exposes simple methods that the app calls. Internally, it holds references to one or more data sources like databases or network clients. When a method is called, the repository decides which data source to use, fetches or saves data, and returns results. This hides complex asynchronous calls and error handling from the rest of the app.

Why designed this way?

The Repository pattern was created to separate concerns and reduce tight coupling between app logic and data sources. Before this pattern, apps often mixed UI and data code, making maintenance hard. By abstracting data access, developers can change or add data sources without rewriting app logic, improving scalability and testability.

App UI/Logic
   │
   ▼
┌───────────────┐
│ Repository    │
│ (interface)   │
└───────────────┘
   │         │
   ▼         ▼
┌───────┐ ┌────────┐
│Cache  │ │Network │
│Layer  │ │Layer   │
└───────┘ └────────┘
   │         │
   ▼         ▼
┌───────────────┐
│ Database      │
│ or API Server │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does the repository pattern mean you always have to use a database? Commit to yes or no.

Common Belief: The repository pattern requires a database as the data source.

Reality: Repositories can use any data source, including web APIs, local files, or in-memory caches. The pattern only defines how to organize data access, not what data source to use.

Why it matters: Believing this limits your design options and may lead to unnecessary complexity or wrong choices.

Quick: Do you think repositories should contain UI code? Commit to yes or no.

Common Belief: Repositories can include UI logic since they handle data for the app.

Reality: Repositories should never contain UI code. Their job is only to manage data access and storage, keeping UI code separate for clarity and maintainability.

Why it matters: Mixing UI and data code makes apps harder to maintain and test.

Quick: Is it true that repositories always improve app performance? Commit to yes or no.

Common Belief: Using repositories automatically makes apps faster.

Reality: Repositories organize code but don't guarantee performance improvements. Performance depends on how data sources and caching are implemented inside the repository.

Why it matters: Assuming repositories fix performance can lead to ignoring real bottlenecks.

Quick: Do you think repositories must be singletons? Commit to yes or no.

Common Belief: Repositories should always be singletons to share data across the app.

Reality: Repositories can be singletons but don't have to be. The choice depends on app needs and architecture. Sometimes multiple instances are better for testing or modularity.

Why it matters: Rigidly making repositories singletons can cause unwanted side effects or testing difficulties.

Expert Zone

1

Repositories often implement caching strategies that balance freshness and speed, which requires careful design to avoid stale data.

2

Combining multiple repositories or layering them allows complex data flows, such as syncing local and remote data sources transparently.

3

Dependency injection frameworks in Flutter, like get_it or Riverpod, can manage repository lifecycles and dependencies, improving app modularity.

When NOT to use

The Repository pattern is less useful for very simple apps with minimal data needs or when data access is trivial. In such cases, direct data calls in UI might be simpler. Also, for apps with highly dynamic or streaming data, reactive patterns without strict repositories might be better.

Production Patterns

In production Flutter apps, repositories are combined with state management (Bloc, Provider, Riverpod) and dependency injection to build scalable, testable architectures. Repositories often handle error mapping, caching, and offline support, making them central to robust app design.

Connections

Dependency Injection

builds-on

Knowing how repositories receive their data sources through dependency injection helps you build flexible and testable apps.

Model-View-ViewModel (MVVM)

complements

Repositories provide the data layer that ViewModels use, separating UI logic from data access cleanly.

Supply Chain Management

similar pattern

Just like repositories manage data flow in apps, supply chains manage goods flow in business, both hiding complexity behind simple interfaces.

Common Pitfalls

#1 Mixing UI code inside repository classes.

Wrong approach:

class UserRepository {
Widget buildUserProfile() {
// fetch user data
// build UI widget
}
}

Correct approach:

class UserRepository {
Future fetchUser() async {
// fetch user data only
}
}

// UI code calls repository and builds widgets separately

Root cause:

Confusing responsibilities leads to tangled code that is hard to maintain.

#2 Hardcoding data sources inside repositories without abstraction.

Wrong approach:

class UserRepository {
final Database db = Database();
Future fetchUser() async {
return db.getUser();
}
}

Correct approach:

abstract class UserDataSource {
Future fetchUser();
}

class DatabaseDataSource implements UserDataSource {
Future fetchUser() async { /* ... */ }
}

class UserRepository {
final UserDataSource dataSource;
UserRepository(this.dataSource);
Future fetchUser() => dataSource.fetchUser();
}

Root cause:

Not using abstraction reduces flexibility and testability.

#3 Ignoring error handling inside repositories.

Wrong approach:

Future fetchUser() async {
return await api.getUser(); // no try-catch
}

Correct approach:

Future fetchUser() async {
try {
return await api.getUser();
} catch (e) {
// handle or rethrow error
}
}

Root cause:

Neglecting errors causes app crashes and poor user experience.

Key Takeaways

The Repository pattern separates data access from app logic, making code cleaner and easier to maintain.

Repositories hide the details of where data comes from, allowing you to change data sources without rewriting your app.

Using abstraction and dependency injection with repositories improves flexibility and testability.

Repositories often combine multiple data sources and caching to improve app performance and offline support.

Avoid mixing UI code or hardcoding data sources inside repositories to keep your app modular and robust.