-
Android
开发中的
MVP
架构
最近越来越多的人开始谈论架构。我周围的同事
和工程师也是如此。尽管我还不是特别深入理解
MVP
和
DDD
，但是我们的新
项目还是决定通过
MVP
来构建。这篇文章是我通过研究和学习各种文章以及专题讨论
所总结出来的。
作者：佚名来源：
安
卓开发精选
|2016-12-08 10:03
收藏
分享
推广
|
令
人窒息的奖品等你
—
2016
最权威的
全球开发者调研
最近越来越多的人开始谈论架构。我周围的同
事和工程师也是如此。尽管我还不是特别深入理解
MVP
和
DDD
，
但是我们的新项目还是决定通过<
/p>
MVP
来构建。
这篇文章是我通过研究和学习各种文章以及专题讨论所总结出来的，它包括以下几点：
?
?
?
?
?
为什么越来越多的人开始关注架构
?
首先，
MVP
是什么
?
哪种架构才是最好的，
MVC
，
MVVM
还是
MVP?
MVP
的利与弊
Show me the
code!!!
代码展示
不幸的，这篇文章将不包括：
?
?
详细生动的代码示例
如何编写测试代码
最后，我将告诉你如何更进一步学习这些专题。
顺便提一下，我于上周在当地的一个研讨会上对
MVP
架构进行了相关演讲。这篇文章与当时的演讲内容相差无
几。
介绍
~Activity
是上帝类
~
首先，让我们思考一下为什么在
Android
开发中如此迫切地需要一个清晰的软件架构。
该段摘自
“
代码大全
第二版
”
：
避免创建神类。避免创建无所不知，无所不能的上帝类。如果一个类需要花费时间从其他类中通过
Get()
和
Set()
检索
数据
(
也就是说，需要深入业务并且告诉它们如何去做
)
，所以是否应该把这些功能函数更好的组织到其它类
< br>而不是上帝类中。
(Riel 1996)
上帝类的维
护成本很高，你很难理解正在进行的操作，并且难以测试和扩展，这就是为什么要避免创建上帝类的
黄金法则。
然而，在
An
droid
开发中，如果你不考虑架构的话，
Activity
类往往会越来越大。这是因为，在
Android
中，允许
View
和其它线程共存于
Activity
内。其实最大的问题莫过于在
Act
ivity
中同时存在业务逻辑和
UI
逻辑。这会增
加测试和维护的成本。
Activity
是上帝
这是为什么需要清晰架构的原因之一。
不仅会造成
Activity
的臃肿，
还会引起其他问题，
如使
Activity
和
Fr
agment
的生命周期变复杂，以及数据绑定等。
什么是
MVP?
MVP
代表
Model
，
View
和
Presenter
。
?
?
?
View
层负责处理用户事件和视图部分的展示。在
Android
中，它可能是
Activity
或者
Fragment
类。
< br>
Model
层负责访问数据。数据可以是远端的
Server API
，本地数据库或者
Sh
aredPreference
等。
Presenter
层是连接
(
或适配
)View
和
Model
的桥梁。
下图是基于
MV
P
架构的模式之一。
View
是
UI
线程。
Presenter
是
View
与
Model<
/p>
之间的适配器。
UseCase
或者
Domain
在
Model
层中，负责从实体获取或载入数据。依赖规则如下：
The Dependency Injection
关键是
，高层接口不知道底层接口的细节，或者更准确地说，高层接口不能，不应该，并且必须不了解底层接口
的细节，是
(
面向
)<
/p>
抽象的，并且是细节隐藏的。
The higher interfaces do not know about
the details of the lower ones
依赖规则
?
Uncle Bob
的
“The
Clean
Architecture”
描述了依赖的规则是什么。
同心圆将软件划分为不同的区域，一般的，随着层级的深入，软件的等级也就越高。外圆是实
现机制，内圆是核
心策略。
这是上面片文章的摘要：
Enitities
：
?
?
?
可以是一个持有方法函数的对象
可以是一组数据结构或方法函数
它并不重要，能在项目中被不同应用程序使用即可
Use Cases
?
?
?
包含特定于应用程序的业务规则
精心
编排流入
Entity
或从
Entit
y
流出的数据
指挥
< br>Entity
直接使用项目范围内的业务规则，从而实现
Use Case
的目标