設計模式是幫助我們解決軟件設計中常見問題的有用模板。

說到應用程序架構，結構設計模式可以幫助我們決定如何組織應用程序的不同部分。

在這種情況下，我們可以使用Repository模式從各種來源（如后端 API）訪問數據對象，并將它們作為類型安全的實體提供給應用程序的領域層（即我們的業務邏輯的所在層）。

在本文中，我們將詳細了解Repository Pattern：

• 它是什么，何時使用
• 一些實際示例
• 使用具體類或抽象類的實現細節及其取舍
• 如何使用Repository測試代碼

我還將分享一個帶有完整源代碼的天氣應用程序示例。

準備好了嗎？讓我們開始吧！

什么是Repository Pattern？

要理解這一點，讓我們來看看下面的架構圖：

圖片

在這種情況下，Repository位于數據層。它們的任務是：

• 將領域模型（或實體）與數據層中數據源的實現細節隔離開來。
• 將數據傳輸對象轉換為領域層可理解的有效實體
• (可選）執行數據緩存等操作

?

上圖顯示的只是架構應用程序的多種可能方法之一。如果您采用不同的架構（如 MVC、MVVM 或簡潔架構），情況會有所不同，但概念是相同的。

還要注意的是，Widget屬于表現層，與業務邏輯或網絡代碼無關。

?

如果您的 widget 直接使用來自 REST API 或遠程數據庫的鍵值對，那您就做錯了。換句話說：不要將業務邏輯與用戶界面代碼混在一起。這會使你的代碼更難測試、調試和推理。

何時使用Repository Pattern？

如果您的應用程序有一個復雜的數據層，其中有許多不同的端點返回非結構化數據（如 JSON），而您希望將這些數據與應用程序的其他部分隔離開來，那么Repository Pattern就非常方便。

廣而言之，以下是我認為最適合使用Repository模式的幾種用例：

• 與 REST API 通信
• 與本地或遠程數據庫（如 Sembast、Hive、Firestore 等）通信
• 與特定設備的 API（如權限、攝像頭、位置等）通信

這種方法的一大好處是，如果您使用的任何第三方應用程序接口發生重大變更，您只需更新版本庫代碼即可。

僅憑這一點，Repository就值得 100%使用。??

讓我們看看如何使用它們！??

實踐中的Repository Pattern

舉個例子，我構建了一個簡單的 Flutter 應用程序（這里是源代碼），從 OpenWeatherMap API 獲取天氣數據。

通過閱讀 API 文檔，我們可以找到如何調用 API，以及一些 JSON 格式響應數據的示例。

Repository模式非常適合抽象掉所有網絡和 JSON 序列化代碼。

例如，這里有一個抽象類，定義了Repository的接口：

abstract class WeatherRepository {
  Future<Weather> getWeather({required String city});
}

上述 WeatherRepository 只有一個方法，但也可以有更多方法（例如，如果您想支持所有 CRUD 操作）。

重要的是，該Repository允許我們為，如何檢索給定城市的天氣定義一個接口。

我們需要用一個具體類來實現 WeatherRepository，該類可以使用網絡客戶端（如 http 或 dio）進行必要的 API 調用：

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

class HttpWeatherRepository implements WeatherRepository {
  HttpWeatherRepository({required this.api, required this.client});
  // custom class defining all the API details
  final OpenWeatherMapAPI api;
  // client for making calls to the API
  final http.Client client;

  // implements the method in the abstract class
  Future<Weather> getWeather({required String city}) {
    // TODO: send request, parse response, return Weather object or throw error
  }
}

所有這些實現細節都與數據層有關，應用程序的其他部分不應該關心或知道這些細節。解析 JSON 數據 當然，我們還必須定義氣象模型類（或實體），以及用于解析 API 響應數據的 JSON 序列化代碼：

class Weather {
  // TODO: declare all the properties we need
  factory Weather.fromJson(Map<String, dynamic> json) {
    // TODO: parse JSON and return validated Weather object
  }
}

請注意，雖然 JSON 響應可能包含許多不同的字段，但我們只需要解析將在用戶界面中使用的字段。我們可以手動編寫 JSON 解析代碼，或者使用代碼生成包（如 Freezed）。

在應用程序中初始化Repository

一旦定義了Repository，我們就需要一種方法來初始化它，并使應用程序的其他部分可以訪問它。執行此操作的語法會根據您選擇的 DI/狀態管理解決方案而改變。下面是一個使用 get_it 的示例：

import 'package:get_it/get_it.dart';

GetIt.instance.registerLazySingleton<WeatherRepository>(
  () => HttpWeatherRepository(api: OpenWeatherMapAPI(), client: http.Client(),
);

下面是另一個使用 Riverpod 軟件包中的提供程序的例子：

import 'package:flutter_riverpod/flutter_riverpod.dart';

final weatherRepositoryProvider = Provider<WeatherRepository>((ref) {
  return HttpWeatherRepository(api: OpenWeatherMapAPI(), client: http.Client());
});

如果你喜歡 flutter_bloc 軟件包，這里也有相應的功能：

import 'package:flutter_bloc/flutter_bloc.dart';

RepositoryProvider<WeatherRepository>(
  create: (_) => HttpWeatherRepository(api: OpenWeatherMapAPI(), client: http.Client()),
  child: MyApp(),
))

底層是一樣的：一旦初始化了Repository，就可以在應用程序的其他任何地方（Widget、模塊、Controller等）訪問它。

抽象類還是具體類？

在創建Repository時，一個常見的問題是：你真的需要一個抽象類嗎？這是個非常合理的問題，因為在兩個類中添加越來越多的方法可能會變得相當乏味：

abstract class WeatherRepository {
  Future<Weather> getWeather({required String city});
  Future<Forecast> getHourlyForecast({required String city});
  Future<Forecast> getDailyForecast({required String city});
  // and so on
}

class HttpWeatherRepository implements WeatherRepository {
  HttpWeatherRepository({required this.api, required this.client});
  // custom class defining all the API details
  final OpenWeatherMapAPI api;
  // client for making calls to the API
  final http.Client client;

  Future<Weather> getWeather({required String city}) { ... }
  Future<Forecast> getHourlyForecast({required String city}) { ... }
  Future<Forecast> getDailyForecast({required String city}) { ... }
  // and so on
}

正如軟件設計中經常出現的情況一樣，答案是：視情況而定。

因此，讓我們來看看每種方法的優缺點。

使用抽象類

優點：我們可以在一個地方看到Repository的接口，而不會感到雜亂無章。

優點：我們可以將Repository換成完全不同的實現（例如 DioWeatherRepository 而不是 HttpWeatherRepository），只需修改一行初始化代碼，因為應用程序的其他部分只知道 WeatherRepository。

缺點：當我們 “跳轉到引用 ”時，VSCode 會有點困惑，它會把我們帶到抽象類中的方法定義，而不是具體類中的實現。

缺點：更多模板代碼。

只使用具體類

優點：減少模板代碼。

優點：“跳轉到引用 ”只適用于一個類中的Repository方法。

缺點：如果我們更改了Repository名稱，那么切換到不同的實現就需要進行更多更改（不過使用 VSCode 對整個項目進行重命名很容易）。

在決定使用哪種方法時，我們還應考慮如何為代碼編寫測試。

使用Repository編寫測試代碼

在測試過程中，一個常見的要求是將網絡代碼換成模擬代碼或 “偽代碼”，這樣我們的測試就能運行得更快、更可靠。

然而，抽象類并不能給我們帶來任何優勢，因為在 Dart 中，所有類都有一個隱式接口。

這意味著我們可以這樣做：

// note: in Dart we can always implement a concrete class
class FakeWeatherRepository implements HttpWeatherRepository {

  // just a fake implementation that returns a value immediately
  Future<Weather> getWeather({required String city}) { 
    return Future.value(Weather(...));
  }
}

換句話說，如果我們打算在測試中模擬我們的Repository，就沒有必要創建抽象類。事實上，像 mocktail 這樣的包就利用了這一點，我們可以這樣使用它們：

import 'package:mocktail/mocktail.dart';

class MockWeatherRepository extends Mock implements HttpWeatherRepository {}

final mockWeatherRepository = MockWeatherRepository();
when(() => mockWeatherRepository.getWeather('London'))
          .thenAnswer((_) => Future.value(Weather(...)));

模擬數據源

在編寫測試時，可以模擬Repository并返回預制響應，就像我們上面做的那樣。但還有另一種方法，那就是模擬底層數據源。讓我們回顧一下 HttpWeatherRepository 是如何定義的：

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

class HttpWeatherRepository implements WeatherRepository {
  HttpWeatherRepository({required this.api, required this.client});
  // custom class defining all the API details
  final OpenWeatherMapAPI api;
  // client for making calls to the API
  final http.Client client;

  // implements the method in the abstract class
  Future<Weather> getWeather({required String city}) {
    // TODO: send request, parse response, return Weather object or throw error
  }
}

在這種情況下，我們可以選擇模擬傳遞給 HttpWeatherRepository 構造函數的 http.Client 對象。下面是一個測試示例，展示了如何做到這一點：

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

class MockHttpClient extends Mock implements http.Client {}

void main() {
  test('repository with mocked http client', () async {
    // setup
    final mockHttpClient = MockHttpClient();
    final api = OpenWeatherMapAPI();
    final weatherRepository =
        HttpWeatherRepository(api: api, client: mockHttpClient);
    when(() => mockHttpClient.get(api.weather('London')))
        .thenAnswer((_) => Future.value(/* some valid http.Response */));
    // run
    final weather = await weatherRepository.getWeather(city: 'London');
    // verify
    expect(weather, Weather(...));
  });
}

最后，你可以根據要測試的內容，選擇是模擬Repository本身還是模擬底層數據源。

了解了如何測試版本庫之后，讓我們回到最初關于抽象類的問題上來。

Repository可能不需要抽象類

一般來說，如果你需要許多符合相同接口的實現，創建抽象類是有意義的。

例如，在 Flutter SDK 中，StatelessWidget 和 StatefulWidget 都是抽象類，因為它們可以被子類化。

但在使用Repository時，您可能只需要一個給定Repository的實現。

您很可能只需要一個特定Repository的實現，您可以將其定義為一個單一的具體類。

最小公分母

把所有東西都放在接口后面，也會使你不得不在具有不同功能的 API 之間選擇最小公分母。

也許某個 API 或后端支持實時更新，這可以用基于 Stream 的 API 來建模。

但如果您使用的是純 REST（不含 websockets），您只能發送一個請求并獲得一個響應，這最好使用基于 Future 的 API 來建模。

處理這個問題非常簡單：只需使用基于流的 API，如果使用的是 REST，則只需返回包含一個值的流即可。

但有時會存在更廣泛的 API 差異。

例如，Firestore 支持事務和批量寫入。這類 API 在源碼中使用了構建器模式，而這種模式不容易抽象為通用接口。

如果遷移到不同的后端，新的 API 很可能會有很大不同。換句話說，面向未來的當前應用程序接口往往不切實際，而且會適得其反。

Repository橫向擴展

隨著應用程序的增長，您可能會發現自己向給定的Repository中添加的方法越來越多。

如果您的后端有很大的 API 列表，或者如果您的應用程序連接到許多不同的數據源，就可能出現這種情況。

在這種情況下，可以考慮創建多個Repository，將相關的方法放在一起。例如，如果您正在構建一個電子商務應用程序，您可以為產品列表、購物車、訂單管理、身份驗證、結賬等創建單獨的Repository。

保持簡單

與往常一樣，保持簡單總是個好主意。因此，不要對應用程序接口想得太多。

您可以根據您需要使用的 API 來構建您的版本庫接口模型，然后就可以收工了。如果需要，您可以隨時重構。??

結論

如果我想讓你從這篇文章中得到什么啟發，那就是：使用Repository模式來隱藏你的代碼：

使用Repository模式來隱藏數據層的所有實現細節（如 JSON 序列化）。這樣，應用程序的其余部分（領域層和表現層）就可以直接處理類型安全的模型類/實體。您的代碼庫也將變得更有彈性，可以抵御您所依賴的包中出現的破壞性變化。

如果說有什么收獲的話，我希望這篇概述能鼓勵您更清晰地思考應用程序架構，以及擁有邊界清晰的獨立表現層、應用層、領域層和數據層的重要性。

本文翻譯自：https://codewithandrea.com/articles/flutter-repository-pattern/