Question

我希望使用Clean Architecture实现一个简单的Firebase身份验证Android应用程序，因此根据Firebase文档，用户可以检查他是否已登录

@Override
public void onStart() {
    super.onStart();
    // Check if user is signed in (non-null) and update UI accordingly.
    FirebaseUser currentUser = mAuth.getCurrentUser();
    updateUI(currentUser);
}

所以我很困惑，因为它应该把这个条件放在哪里，它应该在UseCase中还是在Presenter中，在相同的源对象的帮助下独立调用

类似

public interface FirebaseAuthDataSource {
    Single<User> loginUser(String username, String password);
    Single<User> isUserLoggedIn();
}
public class LoginUserUseCase {
  public Observable<ResponseValues> buildUseCase(RequestValues requestValues) {
   return firebaseAuthDataSource.loginUser(username,password);
  }
}
public class LoginPresenter{
 public void onStart(){
  firebaseAuthDataSource.isUserLoggedIn()
  .subscribe(LoginView::navigateToMenuScreen);
 }
}

这样的条件，它们是否有资格作为业务逻辑？还是流逻辑？

Answer 1

根据Bob叔叔的说法，UI不应该对数据库有任何了解。这些条件属于框架层，其中所有数据库都应该是。通信通过UseCase和数据访问接口。

如果您为此付出了太多努力，那么您也可以将未来可能发生变化的敏感部分转移到＃34; Clean Architecture＆＃34;。但那只是我的意见。我希望这会对你有所帮助

Answer 2

在Clean Architecture中，您将尽可能多的逻辑放入用例层，即交互者。通过在用例层中定义的接口抽象出对数据库等细节的访问，并在框架/接口适配器层中实现。演示者应尽可能简单 - 理想情况下数据转换器＆＃34;仅

在您的情况下，交互者将决定何时进行登录检查并使用firebase DB的接口执行它。交互者还将决定登录检查失败时会发生什么。

如果您想了解有关实施演示者的更多信息，请查看我的帖子：https://plainionist.github.io/Implementing-Clean-Architecture-Controller-Presenter/

Android Clean Architecture中的登录流程

2 个答案: