Android Clean 架构中的登录流程



我希望使用干净的架构实现一个简单的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);
}

所以我很困惑它应该把这个条件放在哪里,它应该在用例中还是在演示器中,在同一源对象的帮助下独立调用

类似的东西

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);
 }
}

所以像这样的条件,它们有资格作为业务逻辑还是流逻辑?

根据鲍勃叔叔的说法,UI 应该不知道有关数据库的任何信息。这些条件属于框架层,所有数据库内容都应该在那里。通信通过用例和数据访问接口。

如果这对您来说太费力了,那么您也可以将将来可能会更改的敏感部分转移到"干净的架构"中。但这只是我的意见。我希望这对你有帮助

在干净的架构中,您将尽可能多的逻辑放入用例层,即交互器。对数据库等细节的访问通过用例层中定义的接口抽象出来,并在框架/接口适配器层中实现。演示者应尽可能简单 - 最好是"数据转换器"。

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

如果您想阅读有关实现演示器的更多信息,请查看我的帖子:https://plainionist.github.io/Implementing-Clean-Architecture-Controller-Presenter/

相关内容

  • 没有找到相关文章

最新更新