设计模式和架构对创建一个成功可靠的应用程序至关重要，可是具备哪些特征才算得上一个好的架构呢？MVP、MVC和MVVM似乎都不错，该如何选择呢？
为什么以及如何选择正确的架构？
如果一开始不在乎架构、后期将会是修复错误和漏洞的噩梦。当然，程序员可以忽略像“Hello World”这样简单的应用程序中的体系结构，也可以忽略一些具有少量代码结构的应用，因为可以直接在View Controller中编写所有代码。一旦代码的量级上去了，画风就彻底变了。我们可以在View Controller中找到一大堆代码，它彻底成为了一个凌乱的视图控制器或大型视图控制器。即使我们遵循MVC指南编程，也可能发生这种情况。
良好架构的定义应该是这样的：
1、实体间平衡分配
2、可读性
3、可测性
4、易于使用和可维护性。
为什么实体之间要平衡分配？
减少复杂性最简单的方法是将不同实体之间的职责分开。它应该遵循单一责任原则，应该有一个唯一的理由来改变。
让我们考虑一个关于在视图中创建pdf并打印该报告的类的示例。现在想象一个可以执行这两个更改的类。首先，它加载来自Web服务器或数据库的数据，其次，它改变了用户界面格式。这两个任务完全不同，第一个是实质性的变化，而设置用户界面完全是一个美化的过程。按照单一责任原则，这两者是独立的责任，实体之间也应该是独立的。这样分配可以保证程序的健壮性。
为什么需要可测性？
可测性并不意味着测试。当一个有效的测试策略用于验证某些实现与其规范的一致性时，应用程序就被认为是可测试的。编写自动化测试非常简单，因为当你完成一个组合根时，它就可以独立测试了。这些测试可以让开发人员在将应用程序交付给用户设备之前查找和修复错误。
为什么易于使用？
程序员都明白，编写的代码越少，错误的机会就越少；拥有的代码越多，错误就越多。如果代码逻辑混乱，维护成本就会相应地上升。好的代码，即使一个新的开发人员接手，也可以轻松掌握。
现在我们有很多设计模式，我们可以根据我们的项目的要求选择：
MVC
MVP
MVVM
MVCModel-View-Controller是用于创建软件应用程序的广泛模式。目前市面上的大多数应用程序和框架都实现了这种设计模式。
Model层是域数据所在的位置，它管理读取和写入数据以及持久状态。诸如持久性、网络代码、模型对象和操纵数据的解析器等保留在这里。
View层是应用程序的面孔，是负责演示（用户界面）并处理用户交互的地方。
Controller层作为黏合剂，也就是Model层和View层之间的中介（模型和视图）。它通过对用户在View中执行的操作进行响应并更新Model层的数据来改变模型。
现在，MVC有什么问题？ 如果我们尝试构建复杂的应用程序，就会变得困难重重。随着时间的推移，越来越多的代码被转移到Controller，使它们更加脆弱和臃肿。Controller与View紧密耦合，如果我们尝试在View中更改某些内容，我们必须回到Controller层并在那里进行更改，这违反了权限特征之间的均衡分配。
谁来拯救MVC架构呢？
MVPMVP代表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不适合简单的应用，它将导致编写样板代码从获得视图的接口开始工作。
MVVMMVVM是最新的模型——视图模式之一。它代表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的优点之一是可视性，因为视图模型与视图无关，因此每个实体都可以单独测试。这种模式不能用于简单的线性屏幕应用程序，否则可能会导致代码更复杂，新开发人员难以维护。
所以，你最喜欢的架构是什么？相关阅读：