[译] Android 架构：Part 4 —— 实践整洁架构

时间  2019-11-08
标签 android 架构 实践 整洁 栏目 Android 繁體版
原文   原文链接

在 Android 架构系列的最后部分，咱们将 Clean Architecture 调整到 Android 平台。咱们将 Android 和真实世界从业务逻辑中分离，令利益相关者满意，使一切都容易测试。前端

理论很棒，可是当咱们建立一个新 Android 项目时，该从哪开始呢？让咱们用整洁代码弄脏咱们的手，把空白画布变成一个架构。java

基础

让咱们先作一些基础工做 —— 建立模块并创建依赖关系，使其与依赖规则保持一致。android

这些将是咱们的模块，从抽象到具体：git

1. domain

实体、用例、仓库接口和设备接口放入 domain 模块。github

理想状况下，实体和业务逻辑应该是平台无关的。为了安全起见，为了防止咱们在这里放置一些 Android 的东西，咱们将使它成为一个纯 java 模块。安全

2. data

data 模块应当持有与数据持久化和操做相关的全部内容。在这里咱们能够找到 DAO、ORM、SharedPreferences、网络相关的好比 Retrofit Service 或相似的东西。网络

3. device

device 模块应该拥有与 Android 相关的全部东西（除了数据持久化 和 UI）。例如 ConnectivityManager, NotificationManager 和 misc 传感器的封装类。架构

咱们将使 data 和 device 模块成为 Android 模块，由于它们必须知道 Android，不能是纯的 java。app

4. 最容易的部分，app 模块（UI 模块）

当你建立项目时，该模块已经由 Android Studio 为你建立好了。框架

在这里，你能够放置与 Android UI 相关的类，譬如 Presenter，Controller，ViewModel，Adapter 以及 View。

依赖

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

你可能会记得本系列的第三部分，UI（app），DB-API（data）以及设备（device）的东西都在外层。这意味着它们在同一抽象级别。那么咱们该如何将它们串在一块儿呢？

理想的状况下，这些模块仅依赖于领域（domain）模块。在这种状况下，依赖关系看起来有点像一颗星：

可是这里咱们涉及 Android 因此事情就不那么完美了。由于咱们须要建立对象依赖图以及初始化一些东西，模块有时依赖另外一个模块而不是领域模块。

例如，咱们须要在 app 模块建立依赖注入的对象依赖图，这就迫使 app 模块须要知道其他全部模块。

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

砖，更多的砖

终于，是时候写些代码了。为了容易演示，咱们将以 RSS 阅读器 app 为例。咱们的用户应该可以管理他们的 RSS Feed 订阅，从 Feed 中获取文章并阅读它们。

领域

让咱们从领域层开始，建立咱们的核心业务模型和逻辑。

咱们的业务模型很是简单：

  • Feed - 持有 RSS Feed 相关数据好比 url、缩略 URL、标题和描述
  • Article - 持有文章相关数据好比文章标题、url 和发表时间

至于咱们的逻辑，咱们将使用 UseCase 也就是交互器。它们将简单类中的小部分业务逻辑封装起来。它们都会实现通常的 UseCase 协议：

public interface UseCase<P> {

   interface Callback {

      void onSuccess();
      void onError(Throwable throwable);
    }

   void execute(P parameter, Callback callback);
 }
复制代码

当用户打开咱们的 app 要作的第一件事情是添加一个新的 RSS Feed 订阅。因此从咱们的交互器开始，咱们建立 AddNewFeedUseCase，以及处理 feed 添加和验证逻辑的辅助类。

AddNewFeedUseCase 使用 FeedValidator 来检查 feed URL 的有效性，咱们还将建立 FeedRepository 协议，它为咱们的业务逻辑提供基础的增删改查能力来管理 feed 数据：

public interface FeedRepository {

    int createNewFeed(String feedUrl);

    List<Feed> getUserFeeds();

    List<Article> getFeedArticles(int feedId);

    boolean deleteFeed(int feedId);
}
复制代码

注意咱们在领域层的命名是如何清晰地说明咱们的 app 是作什么的。

把全部东西放在一块儿，咱们的 AddNewFeedUseCase 看起来像这样：

public final class AddNewFeedUseCase implements UseCase<String> {

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

复制代码

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

如今，你可能会困惑，为何咱们的用例和回调是一个接口？

为了更好地演示咱们下一个问题，让咱们来研究研究 GetFeedArticlesUseCase

得到 feedId -> 经过 FeedRepository 抓取 feed 文章 -> 返回 feed 文章列表

这是数据流问题，用例位于表现层和数据层之间，咱们怎样创建起层和层之间的通讯？记得那些输入和输出端口吗？

咱们的用例必须实现输入端口（interface）。Presenter 调用用例的方法，数据流向用例（feedId）。用例将 feedId 转换成 feed 文章列表，并但愿将其返回给表现层。它拥有指向输出端口（Callback）的引用，由于输出端口是定义在同一层的，因此它调用了输出端口的一个方法。所以数据将发送到输出端口 —— Presenter。

咱们稍微调整一下 UseCase 协议：

public interface UseCase<P, R> {

   interface Callback<R> {
       void onSuccess(R return);
       void onError(Throwable throwable);
   }

   void execute(P parameter, Callback<R> callback);
}

public interface CompletableUseCase<P> {

   interface Callback {
       void onSuccess();
       void onError(Throwable throwable);
   }

   void execute(P parameter, Callback callback);
}
复制代码

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

GetFeedArticlesUseCase 实现以下：

class GetFeedArticlesUseCase implements UseCase<Integer, List<Article>> {

   private final FeedRepository feedRepository;

   @Override
   public void execute(final Integer feedId, final Callback<List<Article>> callback) {
       try {
           callback.onSuccess(feedRepository.getFeedArticles(feedId));
       } catch (final Throwable throwable) {
           callback.onError(throwable);
       }
   }
 }

复制代码

最后一件领域层须要注意的事情是，交互器只应该包含业务逻辑。在这样作时，它们可使用 Repository，组合其它交互器，使用相似咱们例子中 FeedValidator 这样的公共设施类。

UI

很好，咱们能够抓取文章，如今让咱们向用户展现它们。

咱们的 View 有一个简单的协议：

interface View {

   void showArticles(List<ArticleViewModel> feedArticles);
   
   void showErrorMessage();
   
   void showLoadingIndicator();
}
复制代码

此 View 的 Presenter 的表现逻辑很是简单。它抓取文章，转换成视图模型传递给 View，简单吧，对吗？

简单的 Presenter 是 Clean Architecture 和 表现 —— 业务逻辑分离的另外一个伟大成就。

这是咱们的 FeedArticlesPresenter：

class FeedArticlesPresenter implements UseCase.Callback<List<Article>> {

   private final GetFeedArticlesUseCase getFeedArticlesUseCase;
   private final ViewModeMapper viewModelMapper;

   public void fetchFeedItems(final int feedId) {
       getFeedArticlesUseCase.execute(feedId, this);
   }

   @Override
   public void onSuccess(final List<Article> articles) {
       getView().showArticles(viewModelMapper.mapArticlesToViewModels(articles));
   }

   @Override
   public void onError(final Throwable throwable) {
       getView().showErrorMessage();
   }
 }

复制代码

注意 FeedArticlesPresenter 实现了 Callback 接口，并将自身传递给用例，它其实是用例的输出端口，并以这种方式关闭数据流。这是咱们前面提到过的数据流的具体例子，咱们能够在流程图上调整标签来匹配这个例子：

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

你不必定必须使用 Presenter 来处理表现逻辑，咱们能够说，Clean Architecture 是“前端”无关的 —— 这意味着你可使用 MVP，MVC，MVVM 或其余任何东西。

咱们来加点 Rx

若是你想知道为何会有这样关于 RxJava 的炒做，那么来看看咱们的用例的响应式实现：

public interface UseCase<P, R> {

   Single<R> execute(P parameter);         
}

public interface CompletableUseCase<P> {

   Completable execute(P parameter);
}
复制代码

回调接口如今已经消失，咱们使用 RxJava Single / Completable 接口做为输出端口。

响应式 FeedArticlePresenter 的实现以下：

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，Presenter 会实现回调，而使用 RxJava， 订阅者也包含在外层 —— Presenter 的某个地方。

译者注：若是你打算用 ViewModel 取代 Presenter，而且在项目中使用了 RxJava，那么向你安利 使用 RxCommand 在 Android 上实现 MVVM。

Data and Device

data 和 device 模块包含全部业务逻辑不关心的实现细节。它只关系协议，使你容易测试，以及在不触及业务逻辑的状况下更换实现。

这里，你可使用你喜欢的 ORM 或 DAO 来存储本地数据，使用你喜欢的网络服务来从网络获取数据。咱们将实现 FeedService 来拉取文章，使用 FeedDao 来存储文章数据到设备。

每一个数据源（网络和本地存储）都有本身的模型来处理。

在咱们的例子中，它们是 ApiFeed - ApiArticle 和 DbFeed - DbArticle。

FeedRepository 的具体实现也能够在 data 模块中找到。

device 模块持有 Notifications 协议的实现，就是对 NotificationManager 类的一个包装。当有新的用户可能感兴趣并参与的文章发表时，咱们会在咱们的业务逻辑中使用 Notifications 来向用户显示一个通知。

模型，处处都是模型

你可能已经注意到，咱们说起的模型不只仅是实体或业务。

实际上，咱们还有 db 模型，API 模型，视图模型，固然还有业务模型。

每一层都有本身的模型是个不错的实践，这样你的具体细节，譬如视图，就不须要依赖低层实现的具体细节。经过这种方式，举个例子，当你决定更换 ORM 框架时，你就不须要破坏不相干的代码。

为了确保这点，有必要在每一个层中使用对象映射器。在咱们的例子中，咱们使用 ViewModelMapper 将 demain 模块中的 Article 模型映射成 ArticleViewModel

总结

遵循这些准则，咱们建立了健壮且通用的架构。首先，看起要写好多代码，确实也是，可是记住，咱们是为将来的变化和功能搭建咱们的架构。若是你正确地作了，将来你会感谢当初的决定。

在下一部分中，咱们会介绍多是这个架构中最重要的部分，它的可测试性以及如何测试它。那么，在此期间，你对架构实现的哪部分最感兴趣呢？

Part I

Part II

part III

源码

原文

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程