mvc架构
mvc(modal-view-controller)是比较常用的框架，也是早期的后端服务框架，后来随着富客户端的发展，在前端也使用了起来。mvc的目的是把软件分成三个部分，这样关注点分离，便于更好的维护代码，方便进行业务扩展。其各部分的通信如下。
特点： 每个层的通信都是单向通信的。
优点：
- 职责分离：模块化程度高、Controller可替换、可复用性、可扩展性强。
- 多视图更新：使用观察者模式可以做到单Model通知多视图实现数据更新。
缺点：
- 测试困难：View需要UI环境，因此依赖View的Controller测试相对比较困难（现在Web前端的很多测试框架都已经解决了该问题）。
- 依赖强烈：View强依赖Model(特定业务场景)，因此View无法组件化设计。
mvp架构
mvp(modal-presenter-view)只是把controller 换成Presenter，并且去掉了modal和 view之前的通信。其逻辑部署在Presenter中
特点： view 和 presenter 双向通信, presenter和model双向通信，并且切断view和model之间的通信
优缺点：
- Presenter便于测试、View可组件化设计
- Presenter厚、维护困难
mvvm架构
mvp(modal-mv-view) 其中view和mv双向绑定，其中view 的改变会影响mv，mv 的改变会影响view的显示
特点： view 和 model-view 双向绑定
优点：
- 提升了可维护性，解决了MVP大量的手动同步的问题，提供双向绑定机制。
- 简化了测试，同步逻辑是交由Binder处理，View跟着Model同时变更，所以只需要保证Model的正确性，View就正确。
缺点：
- 产生性能问题，对于简单的应用会造成额外的性能消耗。
- 对于复杂的应用，视图状态较多，视图状态的维护成本增加，ViewModel构建和维护成本高。
观察者模式和发布/订阅模式
观察者模式
观察者模式是使用一个subject目标对象维持一系列依赖于它的observer观察者对象，将有关状态的任何变更自动通知给这一系列观察者对象。当subject目标对象需要告诉观察者发生了什么事情时，它会向观察者对象们广播一个通知。
一个或多个观察者对目标对象的状态感兴趣时，可以将自己依附在目标对象上以便注册感兴趣的目标对象的状态变化，目标对象的状态发生改变就会发送一个通知消息，调用每个观察者的更新方法。如果观察者对目标对象的状态不感兴趣，也可以将自己从中分离。
发布/订阅模式
发布/订阅模式使用一个事件通道，这个通道介于订阅者和发布者之间，该设计模式允许代码定义应用程序的特定事件，这些事件可以传递自定义参数，自定义参数包含订阅者需要的信息，采用事件通道可以避免发布者和订阅者之间产生依赖关系。
区别
观察者模式：允许观察者实例对象(订阅者)执行适当的事件处理程序来注册和接收目标实例对象(发布者)发出的通知（即在观察者实例对象上注册update方法），使订阅者和发布者之间产生了依赖关系，且没有事件通道。不存在封装约束的单一对象，目标对象和观察者对象必须合作才能维持约束。 观察者对象向订阅它们的对象发布其感兴趣的事件。通信只能是单向的。
发布/订阅模式：单一目标通常有很多观察者，有时一个目标的观察者是另一个观察者的目标。通信可以实现双向。该模式存在不稳定性，发布者无法感知订阅者的状态。