先看看美女
贝鲁奇架构内容
1. ui模型
2. 业务模型
3. 数据模型
设计需要:
1. ui可以复用,业务可以复用
2. ui易修改易维护,业务容易修改维护。
方案:
1. ui和业务进行分离,数据模型因为简单就组合到业务内部。这样ui可以拿来用,业务也可以拿来用。多个业务可以分块组合拿来用。修改业务不会牵涉到ui内容,修改ui也不会牵涉到业务。关键-分离。
2. ui和业务逻辑分离了,那么他们之间的交互,就需要定义个控制层。控制层,做了ui操作到业务逻辑的转发,业务逻辑的选择,业务逻辑的回馈。这样他的职责也很清晰,不会被业务和ui的变化,堆积而变得臃肿和复杂。
3. 模式的诞生:**mvc** 与 **mvp** 模式
- 在mvc设计中,m为数据模型,c为控制层,v为ui层。在mvp中,p为控制层。
- mvc与mvp相比是:前者的v与m层能够互相通信,没有实现v与m的解耦合,这样会导致业务模块牵涉了太多的ui操作。但是如果m与p交互,那么业务牵涉的就是控制层, 虽然也有牵涉,但是p的迁移是比v的迁移要简单地多的。这就是mvp和mvc的本质差别。
4. 不管哪种我觉得业务逻辑都要写在model层,不要写在控制层,不要写在控制层,不要写在控制层。**重要的事情说三遍**!
- 其一,业务逻辑写在c层,如果增加业务,业务只能以累计的方式堆在c层,没法扩展出多个业务模块,业务的膨胀导致c层的不堪重负,其一后面不好维护,其二业务很多是可以复用的,这么写后面是没法去复用了,最终肯定完蛋。而写在model层则可以实现业务的易扩展,易分模块,可以在c层自由的实现业务模块的组合,更换。c层永远保持年轻。
- 其二,业务逻辑写在c层,业务和ui并没有实现更大的分离与解耦,如果去掉业务接口对ui影响是很大的,更改ui对业务的影响也是大的。 而且在复用的角度上来说,ui与业务关联太紧密也不好复用。
mvp/mvc结构的优点:
1. 业务和ui的分离,可以高度复用ui和业务逻辑。
2. 业务和Ui分离,可以自由地修改任一方,对方的影响都是很小的, 维护性高。
> 备注:android原生并没有提供一个好的mvc模式,Activity既做c又做v,如果不好好设计一下结构,结果就出现了类的悲剧,你懂得......
> 架构只是一种方法论,可以指导行为, 是好的结果的必要条件,但不是充分条件哦。
网友评论