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.

Practice

1. What is the main purpose of the Repository pattern in Flutter app development?

easy

A. To manage app navigation

B. To create UI widgets faster

C. To handle user input events

D. To separate data access logic from UI code

Solution

1. Step 1: Understand the role of Repository pattern

   The Repository pattern is designed to separate data access from the UI, so the UI does not directly handle data fetching or storage.

2. Step 2: Identify the correct purpose

   Among the options, only separating data access logic from UI code matches the Repository pattern's purpose.

3. Final Answer:

   To separate data access logic from UI code -> Option D

4. Quick Check:

   Repository pattern = separate data access from UI [OK]

Hint: Repository = data access separated from UI [OK]

Common Mistakes:

• Confusing Repository with UI widget creation
• Thinking Repository manages navigation
• Assuming Repository handles user input

2. Which of the following is the correct way to declare a repository interface in Dart for fetching a list of users?

easy

A. abstract class UserRepository { Future fetchUsers(); }

B. class UserRepository { List<User> fetchUsers() async {} }

C. interface UserRepository { List<User> fetchUsers(); }

D. abstract UserRepository { Future fetchUsers() List<User>; }

Solution

1. Step 1: Recall Dart syntax for abstract classes

   In Dart, interfaces are created using abstract classes with method signatures but no bodies.

2. Step 2: Check method signature for async fetching

   The method should return a Future to indicate asynchronous fetching.

3. Final Answer:

   abstract class UserRepository { Future fetchUsers(); } -> Option A

4. Quick Check:

   Dart interface = abstract class with Future method [OK]

Hint: Use abstract class with Future return for async methods [OK]

Common Mistakes:

• Using 'interface' keyword which Dart doesn't have
• Missing Future for async methods
• Incorrect method syntax or return type

3. Given this repository implementation snippet, what will be printed?

class UserRepositoryImpl implements UserRepository {
  @override
  Future fetchUsers() async {
    return ['Alice', 'Bob'];
  }
}

void main() async {
  var repo = UserRepositoryImpl();
  var users = await repo.fetchUsers();
  print(users.length);
}

medium

A. 2

B. ['Alice', 'Bob']

C. Error: fetchUsers is not async

D. 0

Solution

1. Step 1: Understand the fetchUsers method

   The method returns a Future with a list containing two strings: 'Alice' and 'Bob'.

2. Step 2: Analyze the main function output

   The code awaits the fetchUsers call, then prints the length of the list, which is 2.

3. Final Answer:

   2 -> Option A

4. Quick Check:

   List length = 2 [OK]

Hint: Count list items returned by async method [OK]

Common Mistakes:

• Confusing printed list with its length
• Ignoring async/await causing errors
• Assuming fetchUsers returns empty list

4. Identify the error in this repository implementation:

class UserRepositoryImpl implements UserRepository {
  Future fetchUsers() {
    return ['Alice', 'Bob'];
  }
}

medium

A. No error, code is correct

B. fetchUsers must return Future, but returns List<String>

C. UserRepositoryImpl should not implement UserRepository

D. Missing async keyword before fetchUsers method

Solution

1. Step 1: Check return type of fetchUsers

   The method signature says it returns Future, but the returned value is a List<String> without wrapping in Future.

2. Step 2: Identify type mismatch and missing Future

   Returning a plain list instead of a Future causes a type mismatch error.

3. Final Answer:

   fetchUsers must return Future, but returns List<String> -> Option B

4. Quick Check:

   Return type mismatch = fetchUsers must return Future, but returns List<String> [OK]

Hint: Check method return matches declared Future type [OK]

Common Mistakes:

• Forgetting to wrap return value in Future
• Ignoring type mismatch between User and String
• Assuming async keyword is always required

5. You want to combine data from a local database and a remote API in your repository. Which approach best follows the Repository pattern principles?

hard

A. Use only remote API and ignore local DB to simplify code

B. Let UI call local DB and remote API separately and merge data itself

C. Create a repository that fetches from local DB first, then updates from remote API, exposing a single method to UI

D. Create two separate repositories and let UI decide which to use

Solution

1. Step 1: Understand Repository pattern goal

   The pattern centralizes data access, hiding multiple sources behind one interface.

2. Step 2: Evaluate options for combining data sources

   Create a repository that fetches from local DB first, then updates from remote API, exposing a single method to UI combines local and remote data inside one repository method, exposing a simple interface to UI, which matches the pattern.

3. Step 3: Reject options that expose data sources to UI

   Options B and D let UI handle data sources, breaking separation. Use only remote API and ignore local DB to simplify code ignores local data, losing benefits.

4. Final Answer:

   Create a repository that fetches from local DB first, then updates from remote API, exposing a single method to UI -> Option C

5. Quick Check:

   Repository hides multiple sources behind one interface [OK]

Hint: Repository hides data sources, exposes one method to UI [OK]

Common Mistakes:

• Letting UI handle multiple data sources
• Ignoring local cache benefits
• Splitting data sources into separate repositories without abstraction