Android 应用架构—— 那些因为年轻犯的错

你应该尽可能地对你的 app 进行单元测试，并且你的架构应该允许你这样做。如果你不能测试所有东西，你至少应该覆盖你的业务逻辑。与真实世界分离可以很方便地做到这点。如果你的业务逻辑清晰地和 app 其余部分隔离，是很容易测试的。

第一次迭代 —— 上帝 Activity

public final class UsersActivity extends ListActivity { 
 
@Override 
protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savedInstanceState); 
 //... 
 new ListUsers().execute(); 
} 
 
private final class ListUsers extends AsyncTask<Void, Void, Void> { 
 
@Override 
protected Void doInBackground(Void... voids) { 
 // final SQLiteOpenHelper sqLiteOpenHelper = ... 
 // JsonObjectRequest jsObjRequest = new JsonObjectRequest 
 // (Request.Method.GET, url, null, new Response.Listener<JSONObject>() { 
 // MySingleton.getInstance(this).addToRequestQueue(jsObjRequest); 
 // showData(user); 
 return null; 
 } 
 } 
} 

你可能在 “上古时代” 看到过这样的代码。如果没有，说明你很年轻。但是这一段代码哪里有问题呢?答案是哪里都有问题。

我们有一个 Activity 操作数据库，访问网络，解析数据，切换线程以及渲染数据。所有的利益相关者都在看这一个类，没有关注点是分离的，它是不可测试的，业务逻辑和 Android 的东西混杂在一起。

译者注：留意上图左边红色的标签。每个标签分别对应一条黄金法则，红色表示不满足。SRP 是指单一职责原则，即分离关注点。

第二次迭代 —— MVP

第一种方法显然是不能工作的。我们尝试过的第一件事情是 MVP，或者说 model-view-presenter。每个人都熟悉 MVP。它是最受欢迎的架构模式之一。看起来像这样：

这里，我们分离了实际上是 Android Fragment 的 View，我们拥有代表我们业务的(领域)模型，最后我们有协调一切的 Presenter。这肯定是更好的。关注点有了一些分离，利益相关者不再那么困惑，你也可以写一些单元测试了。尽管如此，由于 Presenter 直接操作数据库和所有一切，我们仍然和真实世界混杂在一起。Presenter 成了上帝对象。它处理模型，将数据发送到视图，它拥有业务逻辑(业务逻辑是那些齿轮 :))，它访问数据库和网络，获取传感器数据，等等。所以，是好了些，但可以更好。

第三次迭代 —— MVP + managers

当政府不知道做什么的时候它会做什么?它成立一个代理机构。当开发不知道做什么的时候他们会做什么?他们引入一些 Manager。你不一定把它命名为 “*Manager” 。这些类有很多名字：uitls、helpers、fooBarBuzz-ator、等等。因此我们引入 Manager。

说实话，这甚至有点凑效。业务逻辑包含在 Manager 中。利益相关者知道往哪看，关注点一定程度是分离的但可以做得更好，你可以编写更多的测试，但你依然直接触摸 Android ，所以你必须编写 Android 测试用例，并预先填写数据库来测试业务逻辑，一个字：不爽。

是的，Manager 有变成巨兽的倾向，很快就变得难以维护。你可能争论说它不会变得更复杂，你可以通过更简单的架构来更快地提供代码，但通过这种方法依然会有很多 BUG，可维护性也会遭到破坏。

译者注：留意 Manager this 和 Manager that 之间的标签

总结

（编辑：开发网_开封站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!