Android开发中的MVP架构

最近越来越多的人开始谈论架构。我周围的同事和工程师也是如此。虽然我对MVP和DDD的理解不是很深，但是我们的新项目还是决定通过MVP来构建。这篇文章是我对各种文章和研讨会的研究和学习的总结。包括以下几点：为什么越来越多的人关注建筑？首先，什么是MVP？哪种架构是***是的，MVC、MVVM还是MVP？MVP的优缺点给我看代码！！！很遗憾，本文不会包括：详细生动的代码示例如何编写测试代码***，我会告诉你如何更多地了解这些主题。顺便说一下，上周我在当地的一个研讨会上做了一个关于MVP架构的演讲。这篇文章与当时的演讲内容相去不远。引言~Activity是神类~首先让我们思考一下Android开发为什么如此迫切需要一个清晰的软件架构。这段话摘自《TheCodeCompleteSecondEdition》：Avoidcreatgodclasses。避免创造一个无所不知、无所不能的上帝阶级。如果一个类需要花时间通过Get()和Set()从其他类中获取数据（即需要深入到业务中，告诉他们怎么做），是否应该将这些功能函数更好地组织到其他类中？类？而且不属于上帝类别。（Riel1996）上帝类的维护成本很高，你很难理解发生了什么，也很难测试和扩展，这就是为什么黄金法则是避免创建上帝类。但是在Android开发中，如果不考虑架构，Activity类往往会越来越大。这是因为，在Android中，View和其他线程是允许在Activity中共存的。其实最大的问题是Activity里面既有业务逻辑也有UI逻辑。这增加了测试和维护的成本。活动就是上帝，这是需要清晰架构的原因之一。不仅会造成Activity的臃肿，还会带来其他问题，比如Activity和Fragment的生命周期复杂化，数据绑定等。什么是MVP？MVP代表模型、视图和演示者。View层负责处理用户事件和显示部分视图。在Android中，它可能是Activity或Fragment类。模型层负责访问数据。Data可以是远程ServerAPI、本地数据库或SharedPreference等。Presenter层是连接（或适配）View和Model的桥梁。下图是其中一种基于MVP架构的模式。视图是UI线程。Presenter是View和Model之间的适配器。UseCase或Domain位于Model层，负责从实体中获取或加载数据。依赖规则如下：DependencyInjection的关键是高层接口不知道底层接口的细节，或者更准确地说，高层接口不能、不应该、也不能知道底层接口的细节，是（面向）抽象的，是细节隐藏的。上层接口不知道下层依赖规则的细节？Bob大叔的“TheCleanArchitecture”描述了依赖规则是什么。同心圆将软件划分为不同的区域。一般来说，层次越深，软件的层次就越高。外圈是执行机制，内圈是核心战略。这是上面文章的总结：实体：可以是一个持有方法函数的对象可以是一组数据结构或方法函数没关系，它可以被项目中的不同应用程序使用UseCases包含application-具体程序的业务规则是经过精心编排的。流入或流出Entity的数据引导Entity直接使用项目范围内的业务规则，从而达到UseCase的目的。PresentersControllers将UseCase和Entity中的数据转换成最方便的数据外部系统，比如数据库或者网页都可以方便的使用。这些数据完全包含了GUI的MVC架构。ExternalInterfaces,UI,DB所有的细节都定位了，比如数据库细节，Web框架细节等等MVC,MVPorMVVM？那么，哪一个是*最好的呢？哪一个比其他的好？我可以只选择一个吗？答案是不。这些模式的动机是相同的。这就是避免混乱代码、轻松执行单元测试和创建高质量应用程序的方法。就这样。当然，架构模式远不止这三种。而且这两种模型都不是灵丹妙药，它们只是架构模型中的一种，并不是解决问题的唯一途径。这些只是方法、手段，而不是目的和目标。优缺点好吧，让我们回到MVP架构。刚才我们学习了MVP是什么，讨论了MVP和其他流行的架构，介绍了MVC、MVP和MVVM的区别。这是对MVP架构优缺点的总结：**可测试（TDD）可维护（代码重用）易于审查e信息隐藏**冗余缺点，尤其是小型App开发（可能）额外的学习曲线有时间成本在开始编写代码之前（但我敢打赌设计架构对于所有项目开发都是必要的）给我看代码！！！这里只展示了MVP模式的一小部分结构。如果您想了解更多项目或实时代码示例，请参阅文章末尾的“链接和资源”。那里有非常丰富且设计巧妙的示例，大部分托管在Github上，因此您可以克隆、在设备上运行并查看其工作原理。首先，为每个View定义一个接口。/***InterfaceclassesfortheTopview*/publicinterfaceTopView{/***Initializetheview.**e.g.thefacade-patternmethodforhandlingallActionbarsettings*/voidinitViews();/***打开{@linkDatePickerDialog}*/voidopenDatePickerDialog();/***StartListActivity*/voidstartListActivity();}下面我们重写TopView类，主要有以下几点：TopActivity只负责处理事件监听或者展示各个视图组件所有的业务逻辑都必须委托给Presenter类在MVP中，View和Presenter是一一对应的（MVVM中是一对多）@Bind(R.id.calendar_title)TextViewmCalendarTitle;privateTopPresentermTopPresenter;@OverrideprotectedvoidonCreate(BundlesavedInstanceState){super.onCreate(savedInstanceState);setContentView(R.layout.activity_top);ButterKnife.bind(this);//SaveTopPresenterinstanceinamebervariablefieldmTopPresenter=newTopPresenter();mTopPresenter.onCreate(this);}/**从{@linkTopView}接口*/@OverridepublicvoidinitViews(){//Actionbarsettins//seteventlisteners}@OverridepublicvoidopenDatePickerDialog(){DatePickerFragment.newInstance().show(getSupportFragmentManager(),DatePickerFragment.TAG);//donotwritelogichere...alllogicmustbepassedtothePresentermTopPresenter.updateCalendarDate();}@OverridepublicvoidstartListActivity(){startActivity(newIntent(this,ListActivity.class));}}这个是Presenter类，最重要的一点是Presenter只是一个连接View和Model的适配桥梁，比如TopUseCase#saveCalendarDate()隐藏了TopPresenter的细节，TopView也是一样，不需要关心数据结构，你不需要关心业务逻辑是如何工作的。所以你可以对TopUseCase进行单元测试，因为业务逻辑与视图层是分离的。publicclassTopPresenter{@NullableprivateTopViewmView;privateTopUseCasemUseCase;publicTopPresenter(){mUseCase=newTopUseCase();}publicvoidonCreate(@NonNullTopViewtopView){mView=topView;//hereyoucallView'simplementedmethodsmView.initViews();}publicvoidupdateCalendarDate(){//donotviewforgetinstancesis==null){return;}//herelogiccomesStringdateToDisplay=mUseCase.getDateToDisplay(mContext.getResources());mView.updateCalendarDate(dateToDisplay);//这里有savedate,而这个logic是隐藏在UseCaseclassmUseCase.saveCalendarDate();}}当然，虽然业务逻辑实现在Activity类，您仍然可以执行单元测试，但是这很耗时并且有些复杂。运行应用程序可能需要更多时间，相反，您应该充分利用测试库的性能，例如Robolectric。综上所述，这里没有解药，MVP只是解决方案之一。它可以与其他方法结合使用。同样，它也可以在不同的项目中选择性使用。