Do we really need the repository?

[Donny K. Pratama]

Hello! I like this pattern and used it for the most of my projects. But currently, I feel like using repositories just to call the API from the provider is kinda redundant. I want to know more about this, why we should use repository and not using the provider directly from the controller? And if I want to handle errors, should I handle it in the repository, or the controller by rethrowing it like so:

class AuthRepository {
  /// The provider of this repository.
  final AuthProvider provider;

  /// The constructor of this repository.
  AuthRepository({
    required this.provider,
  });

  /// Authenticate the user using `email` and `password`.
  ///
  /// Will throw [HttpException] if the request failed.
  Future<AuthCredential> login(String email, String password) async {
    try {
      final response = await provider.login({'email': email, 'password': password});
      return AuthCredential.fromJson(response.body);
    } catch (e) {
      rethrow;
    }
  }
}

Is that implementation correct? Please let me know!

[Kauê Murakami]

Hi, I'm happy to hear that you are helping with your projects and identified with the pattern!
Come on, the repository is not mandatory if your controller has no interaction with any provider, that is, there are only repositories where you call a db, api or socket etc, just to contextualize.
Now about the redundancy, do you think it is more redundant to make notes for the api call? or make two repositories in two modules with the same function?

This is the purpose of the repository, to be just a repository of appointments for provider functions, that is, you can use SINGLE PROVIDER FUNCTION in several controllers with only one appointment.

Surely you could skip these steps and even do it right in the controller, taking the code shown as an example.

The purpose of the repository then is just to have a file to map its functions, for example, imagine a big controller, let's use 15 functions as an example, in your repository you will have 15 notes for its API, which in turn is usually a cluster of functions, and there is no reason to separate it if it is not a third endpoint, for example a payments api or a local bank, how would you get this function in your provider file? API or DB? Just go to the repository using Ctrl + Click and voyala! You will be sent into your API file directly to your function.

Now let's extrapolate a little further, imagine you have an endpoint in your api class that is used in 5 of these 15 places, like logging out a user at any time for example, I would use a service, but I'm being rude here and I'm saying I always call this api, so we can reuse it, and yes, we will repeat the note in another repository, but for you to see and know that it also provides data for that module.

Everything that provides data to your controller must be external to the module, so we keep different responsibilities.
But as I said, you can directly use the repository and cut a step, I did that in the past before services, and that's why I separated the repositories by modules and not by entities, so that we can reuse dps providers functions with the minimum of boilerplate but that be fully visible, accessible and easy to map.

I will leave the issue open for another day, if you have any doubts I will be available.

[Donny K. Pratama]

Hello again! Thank you so much for the time given to give that such detailed explanation. I think I get the point. I will close this issue as for now and reopen it if there is another question about the repositories.

Have a nice day!