美文网首页
android的应用架构

android的应用架构

作者: 凤鸣游子 | 来源:发表于2020-04-18 17:42 被阅读0次

    先看看美女

    贝鲁奇

    架构内容

        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,如果不好好设计一下结构,结果就出现了类的悲剧,你懂得......

    > 架构只是一种方法论,可以指导行为, 是好的结果的必要条件,但不是充分条件哦。

    相关文章

      网友评论

          本文标题:android的应用架构

          本文链接:https://www.haomeiwen.com/subject/kppvrttx.html