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

第一种方法显然是不能工作的。我们尝试过的第一件事情是 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 之间的标签

总结

在本系列的第一部分，我们经历了搭建实际可用的 Android 架构的挑战。良好的 Android 架构应该满足众多利益相关者的需求，支持关注点分离，强调业务逻辑，隐藏 Framework 的细节，并使你所有的组件都可以测试。在系列的第二部分，我们将向你展示我们如何管理对我们有用的功能。在此之前，你是否有如何创建合适的 Android 工作流的建议?或者你遇到了什么问题?

（编辑：西安站长网）

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