《Android开发中的MVP架构》由会员分享，可在线阅读，更多相关《Android开发中的MVP架构（9页珍藏版）》请在金锄头文库上搜索。
1、Android开发中的MVP架构最近越来越多的人开始谈论架构。我周围的同事和工程师也是如此。尽管我还不是特别深入理解MVP和DDD,但是我们的新 项目还是决定通过MVP来构建。这篇文章是我通过研究和学习各种文章以及专题讨论所总结出来的。作者：佚名来源：安卓开发精选12016-12-08 10:03收藏分享推广I令人窒息的奖品等你一2016最权威的全球开发者调研最近越来越多的人开始谈论架构。我周围的同事和工程师也是如此。尽管我还不是特别深入理解MVP和DDD， 但是我们的新项目还是决定通过MVP来构建。这篇文章是我通过研究和学习各种文章以及专题讨论所总结出来的,它包括以下几点： 为什么越来越多的
2、人开始关注架构？ 首先，MVP是什么？ 哪种架构才是最好的，MVC, MVVM还是MVP? MVP 的利与弊 Show me the code!代码展示不幸的，这篇文章将不包括： 详细生动的代码示例 如何编写测试代码最后，我将告诉你如何更进一步学习这些专题。顺便提一下，我于上周在当地的一个研讨会上对MVP架构进行了相关演讲。这篇文章与当时的演讲内容相差无 几。介绍-Activity是上帝类首先，让我们思考一下为什么在Android开发中如此迫切地需要一个清晰的软件架构。该段摘自“代码大全第二版”：避免创建神类。避免创建无所不知，无所不能的上帝类。如果一个类需要花费时间从其他类中通过Get()和
3、Set() 检索数据(也就是说，需要深入业务并且告诉它们如何去做)，所以是否应该把这些功能函数更好的组织到其它类 而不是上帝类中。(Riel 1996)上帝类的维护成本很高，你很难理解正在进行的操作，并且难以测试和扩展，这就是为什么要避免创建上帝类的 黄金法则。然而，在Android开发中，如果你不考虑架构的话，Activity类往往会越来越大。这是因为，在Android中，允许View 和其它线程共存于 Activity 内。其实最大的问题莫过于在 Activity 中同时存在业务逻辑和 UI 逻辑。这会增 加测试和维护的成本。Activity 是上帝这是为什么需要清晰架构的原因之一。不仅会
4、造成Activity的臃肿，还会引起其他问题，如使Activity和Fragment 的生命周期变复杂，以及数据绑定等。什么是 MVP?MVP 代表 Model， View 和 Presenter。 View层负责处理用户事件和视图部分的展示。在Android中，它可能是Activity或者Fragment类。 Model层负责访问数据。数据可以是远端的Server API，本地数据库或者SharedPreference等。 Presenter层是连接（或适配）View和Model的桥梁。下图是基于MVP架构的模式之一。View是UI线程。Presenter是View与Model之间的适配器。
5、UseCase或者Domain在Model层中，负责从实体获取或载入数据。依赖规则如下：The Dependency Injection关键是，高层接口不知道底层接口的细节，或者更准确地说，高层接口不能，不应该，并且必须不了解底层接口 的细节，是（面向）抽象的，并且是细节隐藏的。The higher interfaces do not know about the details of the lower ones依赖规则?Uncle Bob的“The Clean ArchitectUT述了依赖的规则是什么。同心圆将软件划分为不同的区域，一般的，随着层级的深入，软件的等级也就越高。外圆是实现机
6、制，内圆是核 心策略。这是上面片文章的摘要：Enitities： 可以是一个持有方法函数的对象 可以是一组数据结构或方法函数 它并不重要，能在项目中被不同应用程序使用即可Use Cases 包含特定于应用程序的业务规则 精心编排流入Entity或从Entity流出的数据 指挥Entity直接使用项目范围内的业务规则，从而实现Use Case的目标Presenters Controllers 将Use Case和Entity中的数据转换成格式最方便的数据 外部系统，如数据库或网页能够方便的使用这些数据 完全包含 GUI 的 MVC 架构External Interfaces, UI, DB 所有
7、的细节所在 如数据库细节， Web 框架细节，等等MVC, MVP 还是 MVVM?那么，哪一个才是最好的呢?哪一个比其他的更优秀呢?我能只选择一个吗?答案是， NO。这些模式的动机都是一样的。那就是如何避免复杂混乱的代码，让执行单元测试变得容易，创造高质量应用程序。就这样。当然，远不止这三种架构模式。而且任何一种模式都不可能是银弹，他们只是架构模式之一，不是解决问题的唯 一途径。这些只是方法、手段而不是目的、目标。利与弊OK,让我们回到MVP架构上。刚刚我们了解了什么是MVP,讨论了 MVP以及其它热门架构，并且介绍了 MVC，MVP和MVVM三者间的不同。这是关于MVP架构利与弊的总结：*
8、利 可测试 （TDD） 可维护（代码复用） 容易 Reviewe 信息隐蔽*弊 冗余的，尤其是小型App开发 （有可能）额外的学习曲线 开始编写代码之前需要时间成本（但是我敢打赌，设计架构是所有项目开发所必需的）show me the code!这里仅展示了 MVP模式的一小段结构。如果你想了解更多项目或生动的代码示例，请参考文章末尾的“链接和资 源”。那里有非常丰富和设计巧妙的示例，基本都托管在Github上，以便你能clone，在设备上运行，并了解工作 原理。首先，为每一个 View 定义接口。1./*2.* Interface classes for the Top view3.*/4.
9、public interface TopView 5.6./*7.* Initialize the view.8.*9.* e.g. the facade-pattern method for handling all Actionbar settings10.*/11.void initViews();12.13./*14.* Open link DatePickerDialog15.*/16.void openDatePickerDialog();17.18./*19.* Start ListActivity20.*/21.void startListActivity();22.让我们重写
10、 TopView 类，要点如下： TopActivity只是负责处理事件监听或者展示每个视图组件 所有的业务逻辑必须委托给Presenter类 在 MVP中，View和Presenter是对应的(在 MVVM中是一对多的)1. public class TopActivity extends Activity implements TopView 2.3. / here we use ButterKnife to inject views4. /*5. * Calendar Title6. */7. Bind(R.id.calendar_title)8. TextView mCalendarT
11、itle;9.10. private TopPresenter mTopPresenter;12.Override13.protected void onCreate(Bundle savedInstanceState) 14.super.onCreate(savedInstanceState);15.setContentView(R.layout.activity_top);16.ButterKnife.bind(this);17.18./ Save TopPresenter instance in a meber variable field19.mTopPresenter = new T
12、opPresenter();20.mTopPresenter.onCreate(this);21.22.23./*24.* Overrides method from the link TopView int erfaces25.*/26.27.Override28.public void initViews() 29./ Actionbar settins30.31./ set event listeners32.33.34.Override35.public void openDatePickerDialog() 36.DatePickerFragment.newInstance().sh
13、ow(getSupportFragmentManager(),37.DatePickerFragment.TAG);38.39./ donot write logic here. all logic must be passed to the Presenter40.mTopPresenter.updateCalendarDate();41.42.43.Override44.public void startListActivity() 45.startActivity(new Intent(this, ListActivity.class);46.47.这 是 Presenter 类 ， 最
14、 重 要 的 一 点 是 Presenter 仅 仅 是 连 接 View 与 Model 的 适 配 桥 梁 。 比 如 ， TopUseCase#saveCalendarDate()是对TopPresenter细节隐藏的，同样对TopView也是如此。你不需要关心数据结 构，也不需要关心业务逻辑是如何工作的。因此你可以对 TopUseCase 执行单元测试，因为业务逻辑与视图层是 分离的。1. public class TopPresenter 3. Nullable4. private TopView mView;5.6. private TopUseCase mUseCase;7.8. public TopPresenter() 9. mUseCase = new TopUseCase();10. 11.12. public void onCreate(NonNull TopView topView) 13. mView = topView;14.15. / here you call
