android的应用架构

先看看美女

贝鲁奇

架构内容

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

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