MVP?MVC?移动开发如何选择正确的框架?

Posted 2021-05-01 中电网

设计模式和架构对创建一个成功可靠的应用程序至关重要，可是具备哪些特征才算得上一个好的架构呢?MVP、MVC和MVVM似乎都不错，该如何选择呢?

为什么以及如何选择正确的架构?

如果一开始不在乎架构、后期将会是修复错误和漏洞的噩梦。当然，程序员可以忽略像“Hello World”这样简单的应用程序中的体系结构，也可以忽略一些具有少量代码结构的应用，因为可以直接在View Controller中编写所有代码。一旦代码的量级上去了，画风就彻底变了。我们可以在View Controller中找到一大堆代码，它彻底成为了一个凌乱的视图控制器或大型视图控制器。即使我们遵循MVC指南编程，也可能发生这种情况。

良好架构的定义应该是这样的

☑ 实体间平衡分配

☑ 可读性、可测性

☑ 易于使用和可维护性。

为什么实体之间要平衡分配?

减少复杂性最简单的方法是将不同实体之间的职责分开。它应该遵循单一责任原则，应该有一个唯一的理由来改变。

让我们考虑一个关于在视图中创建pdf并打印该报告的类的示例。现在想象一个可以执行这两个更改的类。首先，它加载来自Web服务器或数据库的数据，其次，它改变了用户界面格式。这两个任务完全不同，第一个是实质性的变化，而设置用户界面完全是一个美化的过程。按照单一责任原则，这两者是独立的责任，实体之间也应该是独立的。这样分配可以保证程序的健壮性。

为什么需要可测性?

可测性并不意味着测试。当一个有效的测试策略用于验证某些实现与其规范的一致性时，应用程序就被认为是可测试的。编写自动化测试非常简单，因为当你完成一个组合根时，它就可以独立测试了。这些测试可以让开发人员在将应用程序交付给用户设备之前查找和修复错误。

为什么易于使用?

程序员都明白，编写的代码越少，错误的机会就越少;拥有的代码越多，错误就越多。如果代码逻辑混乱，维护成本就会相应地上升。好的代码，即使一个新的开发人员接手，也可以轻松掌握。

现在我们有很多设计模式，我们可以根据我们的项目的要求选择：

• MVC

• MVP

• MVVM

MVC

Model-View-Controller是用于创建软件应用程序的广泛模式。目前市面上的大多数应用程序和框架都实现了这种设计模式。

Model层是域数据所在的位置，它管理读取和写入数据以及持久状态。诸如持久性、网络代码、模型对象和操纵数据的解析器等保留在这里。

View层是应用程序的面孔，是负责演示(用户界面)并处理用户交互的地方。

Controller层作为黏合剂，也就是Model层和View层之间的中介(模型和视图)。它通过对用户在View中执行的操作进行响应并更新Model层的数据来改变模型。

现在，MVC有什么问题? 如果我们尝试构建复杂的应用程序，就会变得困难重重。随着时间的推移，越来越多的代码被转移到Controller，使它们更加脆弱和臃肿。Controller与View紧密耦合，如果我们尝试在View中更改某些内容，我们必须回到Controller层并在那里进行更改，这违反了权限特征之间的均衡分配。

谁来拯救MVC架构呢?

MVP

MVP代表Model-View-Presenter; Cocoa对MVC承诺可在MVP身上实现。它实现了可测试的和清晰的View和Model层分离。

该Model层与MVC模型相同，它管理读写数据和持久状态，这部分没有变化。

View部分包括视图和视图控制器。此处的视图将用户交互委托给Presenter层，MVP中的视图可能比较愚蠢，并且不包含可以查询模型的逻辑。

Presenter层包含处理用户交互的逻辑。它没有任何UIKit依赖关系。Presenter的责任是与Model层进行通信，将数据转换为用户友好的格式，然后更新View层。

在MVP中，视图控制器被视为View的子类，而不是Presenter。责任分配在Model和Presenter之间，因为View不包含任何逻辑，从而实现均衡的特征分配。代码现在更整洁，可以轻松地为Presenter进行单元测试。

我们不能说MVP是一个完美的模式，或者是不是应该遵循MVP，而不需要符合应用程序的要求。 MVP不适合简单的应用，它将导致编写样板代码从获得视图的接口开始工作。

MVVM

MVVM是最新的模型——视图模式之一。它代表Model-View-ViewModel。ViewModel是观察者设计模式的实现，其中model中的任何更改都将在View和ViewModel中表示出来。现在，当我们考虑使用MVVM时，我们会考虑使用Reactive Cocoa，尽管可以使用简单的绑定来构建MVVM模式。MVVM包括：

Model：表示应用程序消耗的数据模型。此类声明属性以类似于上述两种设计的方式来管理业务数据。

View：它类似于MVP。MVVM视图包括视图和视图控制器。它只是保存数据并将所有内容委托给Model的层。

ViewModel：ViewModel作为模型和视图之间的链接。它负责包装模型并准备视图所需的可观察数据。

人们可以通过记住一些要点来使用MVVM：

• view层很笨，只知道如何呈现数据。

• controller对model层一无所知。

• model不了解viewmodel。

• viewmodel拥有model。

• view controller拥有view。

• controller拥有view model，并通过ViewModel与model层进行交互。

MVVM几乎满足了所有功能，该架构的责任分配在viewmodel和view之间。使用MVVM的优点之一是可视性，因为视图模型与视图无关，因此每个实体都可以单独测试。这种模式不能用于简单的线性屏幕应用程序，否则可能会导致代码更复杂，新开发人员难以维护。

MVP如何解决MVC的问题？

在MVP里，Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里实现。而且，Presenter与具 体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变，即重用！ 不仅如此，我们还可以编写测试用的View，模拟用户的各种操作，从而实现对Presenter的测试—而不需要使用自动化的测试工具。 我们甚至可以在Model和View都没有完成时候，就可以通过编写Mock Object（即实现了Model和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很大的不同之处。

MVP的优点

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

热 点 图 文 推 荐

点击“阅读原文”查看更多