mvc
传统的项目架构
- 痛点：
- 随业务需求的变更和迭代会导致单个activity或fragment类十分的臃肿
- 有新需求或改动时，需要去通读之前的业务代码，改动时会改动整个类的代码需要十分谨慎，谨防改动带来的连锁问题，需要消耗较大的精力。
因此需要去考虑如何解耦，拆分activity、fragment，合理的设计安置代码，让代码框架面对业务变更时更加灵活。
mvp
mvp代码框架 解耦了activity(controller层)，将原本存在于activity中的界面、数据处理逻辑、业务处理逻辑拆分
- 解决的痛点：
- 引入presenter、model，有效的拆分出activity的代码，解耦view和model，数据的处理和界面的展示完全隔离，界面展示的改动或者数据处理逻辑改动不需要去修改整个类。
- 对于变动较大的p和v 可以通过抽象相互依赖，符合依赖倒置，拥抱变化。
- 业务代码被单独出来，代码结构会比较清晰.
- 痛点：
- 引入presenter，model能有效的拆分出activity的代码，解耦view和model，但是当业务逻辑足够复杂时，可以预见p层将会同样变得很臃肿。
- 注意点：
viewInterface的设计将直接影响到p层的复杂度
mvp 延伸：
p层会因业务逻辑复杂而变得臃肿 针对此又出现了mvp-clean，mvp-dragger，mvp-rxjava框架来解耦p层
mvvm
与mvp和mvc代码框架不同的是，mvvm的核心是处理数据
通过DataBinding或liveData将数据bean和界面控件双向绑定，在数据发生改变时，界面自动响应做出变化，用数据驱动界面
- 解决的痛点：
- 关注点转移：不需要再去关注何时刷新界面，只需关注数据的处理。
- 只需要控制实体类bean的数据 就可以控制界面的展示，能拆分开view和业务逻辑的强相关 更加专注于业务代码逻辑处理
- 解耦：view-model-业务逻辑层(p)，不存在强相关，同一个界面的view和viewmodel可以分配给多个人负责，两者同时进行开发没有影响
mvvm延伸：
vue angluar前端框架为什么受到那么多人的支持和拥护？个人认为就是因为它们将数据和界面完全隔离开来，将开发的侧重点转向如何操作数据变化。
