Skip to content

Latest commit

 

History

History
88 lines (64 loc) · 5.65 KB

MVC与MVP及MVVM.md

File metadata and controls

88 lines (64 loc) · 5.65 KB

MVC与MVP及MVVM

MVC

MVC是一种使用Model View Controller模型-视图-控制器设计创建Web应用程序的模式:

  • Model（模型）表示应用程序核心（比如数据库记录列表）是应用程序中用于处理应用程序数据逻辑的部分。
  • View（视图）显示数据（数据库记录）是应用程序中处理数据显示的部分。
  • Controller（控制器）处理输入（写入数据库记录）应用程序中处理用户交互的部分。

MVC 分层有助于管理复杂的应用程序，因为您可以在一个时间内专门关注一个方面。例如，您可以在不依赖业务逻辑的情况下专注于视图设计。同时也让应用程序的测试更加容易。 MVC 分层同时也简化了分组开发。不同的开发人员可同时开发视图、控制器逻辑和业务逻辑。

  • 优点

    • 耦合性低
    • 重用性高
    • 可维护性高
    • 有利软件工程化管理

  • 缺点

    • 没有明确的定义
    • 视图与控制器间的过于紧密的连接
    • 增加系统结构和实现的复杂性

image

MVP

MVP是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。 作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter(MVC中的Controller)来进行的， 所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过Controller。 在MVC里,View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。 在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示及View。所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。 不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。

image

在MVP里，Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里实现。而且Presenter与具体的View是没有直接关联的， 而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变，即重用！ 在MVP里，应用程序的逻辑主要在Presenter来实现，其中的View是很薄的一层。因此就有人提出了Presenter First的设计模式， 就是根据User Story来首先设计和开发Presenter。在这个过程中，View是很简单的，能够把信息显示清楚就可以了。 在后面，根据需要再随便更改View，而对Presenter没有任何的影响了。 如果要实现的UI比较复杂，而且相关的显示逻辑还跟Model有关系， 就可以在View和Presenter之间放置一个Adapter。由这个Adapter来访问Model和View，避免两者之间的关联。 而同时，因为Adapter实现了View的接口，从而可以保证与Presenter之间接口的不变。这样就可以保证View和Presenter之间接口的简洁， 又不失去UI的灵活性。在MVP模式里，View只应该有简单的Set/Get的方法，用户输入和设置界面显示的内容，除此就不应该有更多的内容， 绝不容许直接访问Model这就是与MVC很大的不同之处。

  • 优点

    • 模型与视图完全分离，我们可以修改视图而不影响模型
    • 可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部
    • 我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
    • 如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）

  • 缺点 由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁。还有一点需要明白，如果Presenter过多地渲染了视图， 往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了。 比如说，原本用来呈现Html的Presenter现在也需要用于呈现Pdf了，那么视图很有可能也需要变更。

MVVM

MVVM是Model-View-ViewModel的简写。

MVVM模式将Presener改名为View Model，基本上与MVP模式完全一致，同样是以VM为核心，但是不同于MVP，MVVM采用了数据双向绑定的方案，替代了繁琐复杂的DOM操作。 该模型中，View与VM保持同步，View绑定到VM的属性上，如果VM数据发生变化，通过数据绑定的方式，View会自动更新视图；VM同样也暴露出Model中的数据。

看起来MVVM很好的解决了MVC和MVP的不足，但是由于数据和视图的双向绑定，导致出现问题时不太好定位来源，有可能数据问题导致，也有可能业务逻辑中对视图 属性的修改导致。如果项目中打算用MVVM的话可以考虑使用官方的架构组件ViewModel、LiveData、DataBinding去实现MVVM

  • 优点 MVVM模式和MVC模式一样，主要目的是分离视图View和模型Model
  • 低耦合。
  • 可重用性。
  • 独立开发。
  • 可测试。