2017-03-27 4 views
0

Je crée une application de chat en utilisant une architecture propre, je veux vérifier si l'utilisateur est connecté lorsque la application démarre et ouvrez l'écran de connexion s'il est pas connecté, donc mes questions sont les suivantes:Quelle est la différence entre les dépôts et les cas d'utilisation?

  1. Quelle est la meilleure façon de mettre en œuvre cela? Dois-je faire l'activité du lanceur LoginActivity et vérifier quand le LoginPresenter démarre si l'utilisateur est déjà connecté, puis ouvrir le MainActivity? Et où devrais-je mettre la logique pour vérifier si l'utilisateur est authentifié (IsLoggedInUseCase peut-être?)?

  2. Je ne comprends pas vraiment quelle est la différence entre les dépôts et usecases, pourquoi devrais-je faire un GetAllUsersUseCase et EditUserUseCase .. etc, quand il y a déjà UsersRepository.getAllUsers() et UsersRepository.editUser(User user)? Pourquoi créer une classe entière juste pour référencer la méthode qui existe déjà dans le référentiel?

Répondre

1

Simplement, Use-Cases gère votre logique métier, Repositories sont la couche de données vous permet de stocker et accéder aux données.

Par exemple, lorsque vous ouvrez l'activité de lancement (Appelons SplashActivity)

D'abord, vous commencez votre Presenter:

mSplashPresenter.start(); 

En second lieu, dans votre méthode de démarrage de l'animateur vous implémentez une logique si l'utilisateur est connecté en ou non? Si vous vous connectez, accédez au tableau de bord, sinon naviguez jusqu'à LoginActivity. Je suppose que vous avez un LoginUseCase. Troisièmement, vous avez besoin d'une méthode de cas d'utilisation semblable à celle qui suit. (Encore une fois je suppose que vous avez un UserRepository)

public boolean isLoggedIn(){ 
    // This is your business logic. 
    return mUserRepository.getCurrentUser() != null; 
} 

Et dans votre User Repository:

public User getCurrentUser(){ 
    // This is your data 
    // You can access remote or local data with repository. 
    return mLocalDataSource.getUser(); 
} 

Alors, pourquoi nous avons besoin d'une utilisation-cas? C'est une logique métier simple qui décide si l'utilisateur est connecté ou non. Cela peut être une logique métier plus complexe ou vous voulez utiliser cette logique dans d'autres présentateurs. Ainsi, avec Use-Cases, vous rendez votre code d'entreprise réutilisable et évitez les doublons de code dans vos présentateurs. Plus tard, si vous voulez décider de changer votre logique de connexion, vous changez seulement votre cas d'utilisation, pas tous les présentateurs.

Définissons une logique pour votre question: EditUser.

Vous avez une méthode de référentiel UsersRepository.editUser(User user) qui édite l'utilisateur.

Vous avez un écran Profile qui permet de modifier tous les champs. En outre vous avez un écran EditScreenDetail que l'utilisateur peut éditer certains des champs qui se rapportent par des détails d'écran peuvent être vus par d'autres personnes.

Dans les deux écran éditer l'utilisateur mais avant d'appeler la méthode UserRepository vous devez cocher les champs requis qui est différent par deux écrans. Donc vous définissez un ProfileEditUseCase et ScreenDetailsEditUseCase pour implémenter deux logique métier différente. Mais l'opération finale est la même. Vous éditez l'utilisateur par votre repo. De distant ou local.

Résumé:

Avec Use-Cases vous séparez votre logique métier de présentateurs et de la couche de données, évitez de double code dans vos présentateurs. Aussi vous gérez votre entreprise qui peut être utilisée dans d'autres parties d'une classe.

J'espère que je l'ai expliqué clairement.

+0

Est-ce que 'LoginUseCase' devrait contenir une seule méthode,' isLoggedIn() 'dans ce cas? Pourquoi ne pas avoir cette logique dans le dépôt, quelque chose comme 'UserRepository.isLoggedIn()' au lieu de créer une toute nouvelle classe? –

+1

@ MathewHany Dans la plupart des cas, Si vous combinez plusieurs méthodes dans une méthode, c'est une logique. Normalement, nous devrions faire toutes les combinaisons de méthodes dans les méthodes de cas d'utilisation. Donc, nous touchons seulement le cas d'utilisation, si nous voulons changer de logique plus tard. La couche du référentiel doit être aussi factices que possible. Le référentiel est uniquement responsable de récupérer/sauvegarder les données. Nous ne demandons pas au dépôt 'isLoggedIn()', nous demandons 'getSession()'. – mertsimsek