注册
登录
| 关键词： nbsp 架构 MVP Activity 数据 代码 View 一个 上帝 细节 | ||
最近越来越多的人开始谈论架构。我周围的同事和工程师也是如此。尽管我还不是特别深入理解MVP和DDD，但是我们的新项目还是决定通过MVP来构建。 这篇文章是我通过研究和学习各种文章以及专题讨论所总结出来的，它包括以下几点：
不幸的，这篇文章将不包括：
最后，我将告诉你如何更进一步学习这些专题。 顺便提一下，我于上周在当地的一个研讨会上对MVP架构进行了相关演讲。这篇文章与当时的演讲内容相差无几。 （译者注：阅读更多请点击原作者PPT） 介绍~Activity是上帝类~首先，让我们思考一下为什么在Android开发中如此迫切地需要一个清晰的软件架构。 该段摘自“代码大全第二版”：
上帝类的维护成本很高，你很难理解正在进行的操作，并且难以测试和扩展，这就是为什么要避免创建上帝类的黄金法则。 然而，在Android开发中，如果你不考虑架构的话，Activity类往往会越来越大。这是因为，在Android中，允许View和其它线程共存于Activity内。其实最大的问题莫过于在Activity中同时存在业务逻辑和UI逻辑。这会增加测试和维护的成本。  Activity是上帝 这是为什么需要清晰架构的原因之一。不仅会造成Activity的臃肿，还会引起其他问题，如使Activity和Fragment的生命周期变复杂，以及数据绑定等。 什么是MVP？MVP代表Model，View和Presenter。
下图是基于MVP架构的模式之一。View是UI线程。Presenter是View与Model之间的适配器。UseCase或者Domain在Model层中，负责从实体获取或载入数据。依赖规则如下：  The Dependency Injection 关键是，高层接口不知道底层接口的细节，或者更准确地说，高层接口不能，不应该，并且必须不了解底层接口的细节，是（面向）抽象的，并且是细节隐藏的。  The higher interfaces do not know about the details of the lower ones 依赖规则？Uncle Bob的“The Clean Architecture”描述了依赖的规则是什么。
这是上面片文章的摘要： Entities：
Use Cases
Presenters,，Controllers
External Interfaces, UI, DB
MVC，MVP还是MVVM？那么，哪一个才是最好的呢？哪一个比其他的更优秀呢？我能只选择一个吗？ 答案是，NO。 这些模式的动机都是一样的。那就是如何避免复杂混乱的代码，让执行单元测试变得容易，创造高质量应用程序。就这样。 当然，远不止这三种架构模式。而且任何一种模式都不可能是银弹，他们只是架构模式之一，不是解决问题的唯一途径。这些只是方法、手段而不是目的、目标。 利与弊OK，让我们回到MVP架构上。刚刚我们了解了什么是MVP，讨论了MVP以及其它热门架构，并且介绍了MVC，MVP和MVVM三者间的不同。这是关于MVP架构利与弊的总结： **利
**弊
Show me the code!!!这里仅展示了MVP模式的一小段结构。如果你想了解更多项目或生动的代码示例，请参考文章末尾的“链接和资源”。那里有非常丰富和设计巧妙的示例，基本都托管在Github上，以便你能clone，在设备上运行，并了解工作原理。 首先，为每一个View定义接口。
让我们重写TopView类，要点如下：
|
