Android架构：第四部分-在Android上应用Clean架构，实践（包含源代码）(译)-白红宇

Android架构：第四部分-在Android上应用Clean架构，实践（包含源代码）(译)

阅读量：5967 次

发布时间：2019-06-19

本文共 7909 字，大约阅读时间需要 26 分钟。

在Android Architecture系列的最后一部分，我们将Clean Architecture稍微调整到了Android平台。我们将Android和现实世界从业务逻辑中分离出来，让满意的利益相关者满意，并让所有事情都可以轻松测试。

这个理论很好，但是当我们创建一个新的Android项目时，我们从哪里开始？让我们用干净的代码弄脏我们的手，并将空白的画布变成一个架构。

基础

我们将首先奠定基础 - 创建模块并建立它们之间的依赖关系，以便与依赖规则保持一致。

这些将是我们的模块，从最抽象的一个到具体的实现：

1. domain

Entities, use cases, repositories interfaces, 和 device interfaces 进入 domain module。

理想情况下，实体和业务逻辑应该是平台不可知的。为了安全起见，为了防止我们在这里放置一些Android的东西，我们将使它成为一个纯粹的Java模块。

2. data

数据模块应包含与数据持久性和操作相关的所有内容。在这里，我们将找到DAO，ORM，SharedPreferences，网络相关的东西，例如Retrofit服务和类似的东西。

3. device

设备模块应该包含与Android相关的所有内容，而不是数据持久性和UI。例如，ConnectivityManager，NotificationManager和misc传感器的包装类。

我们将使数据和设备模块都是Android模块，因为他们必须了解Android并且不能是纯Java。

4. The easiest part, app module (UI module)

创建项目时，Android模块已经为您创建了该模块。

在这里，您可以放置与Android UI相关的所有类，例如presenters，controllers，view models，adapters和views。

依赖

依赖规则定义具体模块依赖于更抽象的模块。

您可能还记得，从本系列的第三部分可以看出，UI（应用程序），DB-API（数据）和Device（设备）等东西都在外环中。这意味着它们处于相同的抽象层次。我们如何将它们连接在一起呢？

理想情况下，这些模块仅取决于域模块。在这种情况下，依赖关系看起来有点像明星：

但是，我们在这里与Android打交道，事情并不完美。因为我们需要创建对象图并初始化事物，所以模块有时依赖于domain以外的其他模块。

例如，我们正在app模块中创建用于依赖注入的对象图。这迫使APP模块了解所有其他模块。

我们调整后的依赖关系图：

最后，是时候编写一些代码。为了更容易，我们将以RSS Reader APP为例。我们的用户应该能够管理他们的RSS提要订阅，从提要中获取文章并阅读它们。

Domain

让我们从domain层开始，创建我们的核心业务模型和逻辑。

我们的商业模式非常简单：

Feed - 持有RSS提要相关数据，如网址，缩略图网址，标题和说明

Article -保存文章相关数据，如文章标题，网址和发布日期

而对于我们的逻辑，我们将使用UseCases。他们在简洁的类中封装了小部分业务逻辑。他们都将实施通用的UseCase 契约类：

12345678910

public interface UseCase {   interface Callback {      void onSuccess();      void onError(Throwable throwable);    }   void execute(P parameter, Callback callback); }

我们的用户在打开我们的应用时首先要做的就是添加一个新的RSS订阅。因此，要开始使用我们的Use Case，我们将创建AddNewFeedUseCase及其助手来处理Feed的添加和验证逻辑。

AddNewFeedUseCase将使用FeedValidator来检查Feed URL的有效性，并且我们还将创建FeedRepository 契约类，这将为我们的业务逻辑提供一些基本的CRUD功能来管理供稿数据：

12345678910

public interface FeedRepository {    int createNewFeed(String feedUrl);    List
        
          getUserFeeds();    List
         
           getFeedArticles(int feedId);    boolean deleteFeed(int feedId);}

请注意我们在Domain层的命名是如何清楚地传递我们的APP正在做什么的想法。

把所有东西放在一起，我们的AddNewFeedUseCase看起来像这样：

1234567891011121314151617181920212223

public final class AddNewFeedUseCase implements UseCase
        
          {   private final FeedValidator feedValidator;   private final FeedRepository feedRepository;   @Override   public void execute(final String feedUrl, final Callback callback) {       if (feedValidator.isValid(feedUrl)) {           onValidFeedUrl(feedUrl, callback);       } else {           callback.onError(new InvalidFeedUrlException());       }   }   private void onValidFeedUrl(final String feedUrl, final Callback callback) {       try {           feedRepository.createNewFeed(feedUrl);           callback.onSuccess();       } catch (final Throwable throwable) {           callback.onError(throwable);       }   }}

ps:为简洁起见，省略构造函数。

现在，您可能想知道，为什么我们的use case以及我们的回调是一个接口？

为了更好地展示我们的下一个问题，让我们来研究GetFeedArticlesUseCase。

它需要一个feedId - >通过FeedRespository获取提要文章 - >返回提要文章

这里是数据流问题，用例介于表示层和数据层之间。我们如何建立层之间的沟通？记住那些输入和输出端口？

我们的 Use Case必须实现输入端口（接口）。 Presenter在 Use Case上调用方法，数据流向 Use Case（feedId）。 Use Case映射feedId提供文章并希望将它们发送回表示层。它有一个对输出端口（回调）的引用，因为输出端口是在同一层定义的，因此它调用了一个方法。因此，数据发送到输出端口 - Presenter。

我们将稍微调整我们的UseCase契约类：

123456789

public interface UseCase
        
          {   interface Callback
         
           {       void onSuccess(R return);       void onError(Throwable throwable);   }   void execute(P parameter, Callback
          
            callback);}

123456789

public interface CompletableUseCase {   interface Callback {       void onSuccess();       void onError(Throwable throwable);   }   void execute(P parameter, Callback callback);}

UseCase接口是输入端口，Callback接口是输出端口。

GetFeedArticlesUseCase实现如下：

12345678910111213

class GetFeedArticlesUseCase implements UseCase
        
         > {   private final FeedRepository feedRepository;   @Override   public void execute(final Integer feedId, final Callback
         
          
           > callback) {       try {           callback.onSuccess(feedRepository.getFeedArticles(feedId));       } catch (final Throwable throwable) {           callback.onError(throwable);       }   } }

在Domain层中要注意的最后一件事是Interactors应该只包含业务逻辑。在这样做的时候，他们可以使用存储库，结合其他交互器，并在我们的例子中使用一些实用工具对象，如FeedValidator。

UI

太棒了，我们可以获取文章，让我们现在将它们展示给用户。

我们的View有一个简单的契约类：

12345678

interface View {   void showArticles(List
        
          feedArticles);      void showErrorMessage();      void showLoadingIndicator();}

该视图的Presenter具有非常简单的显示逻辑。它获取文章，将它们映射到view odels并传递到View，很简单，对吧？

简单的presenters是Clean架构和presentation - business逻辑分离的又一壮举。

这里是我们的FeedArticlesPresenter：

12345678910111213141516171819

class FeedArticlesPresenter implements UseCase.Callback
        
         
          > {   private final GetFeedArticlesUseCase getFeedArticlesUseCase;   private final ViewModeMapper viewModelMapper;   public void fetchFeedItems(final int feedId) {       getFeedArticlesUseCase.execute(feedId, this);   }   @Override   public void onSuccess(final List
          
            articles) {       getView().showArticles(viewModelMapper.mapArticlesToViewModels(articles));   }   @Override   public void onError(final Throwable throwable) {       getView().showErrorMessage();   } }

请注意，FeedArticlesPresenter实现了Callback接口，并将其自身传递给use case，它实际上是use case的输出端口，并以这种方式关闭了数据流。这是我们前面提到的数据流的具体示例，我们可以在流程图上调整标签以匹配此示例：

我们的参数P是feedId，返回类型R是文章列表。

您不必使用Presenter来处理显示逻辑，我们可以说Clean架构是“前端”不可知的 - 这意味着您可以使用MVP，MVC，MVVM或其他任何东西。

让我们在混合中抛出一些Rx

现在，如果你想知道为什么有这样的RxJava，我们将看看我们UseCase的反应式实现：

1234	public interface UseCase { Single execute(P parameter); }

1234	public interface CompletableUseCase { Completable execute(P parameter); }

回调接口现在不见了，我们使用RxJava Single / Completable接口作为我们的输出端口。

Reactive GetFeedArticlesUseCase：

123456789

class GetFeedArticlesUseCase implements UseCase
        
         > {   private final FeedRepository feedRepository;      @Override   public Single
         
          
           > execute(final Integer feedId) {       return feedRepository.getFeedArticles(feedId);   }}

Reactive FeedArticlePresenter 如下：

123456789101112131415161718192021

class FeedArticlesPresenter {    private final GetFeedArticlesUseCase getFeedArticlesUseCase;   private final ViewModeMapper viewModelMapper;    public void fetchFeedItems(final int feedId) {       getFeedItemsUseCase.execute(feedId)                  .map(feedViewModeMapper::mapFeedItemsToViewModels)                  .subscribeOn(Schedulers.io())                  .observeOn(AndroidSchedulers.mainThread())                  .subscribe(this::onSuccess, this::onError);   }    private void onSuccess(final List articleViewModels) {      getView().showArticles(articleViewModels);   }    private void onError(final Throwable throwable) {      getView().showErrorMessage();   }}

虽然它有点隐藏，但同样的数据流反演原理仍然存在，因为没有RxJava Presenters实现回调，并且RxJava订阅者也包含在外层 - 在Presenter的某处。