1. MVC (Model-View-Controller)
MVC 是最古老的模式，可追溯到近 50 年前。
·Model：封装了数据以及对数据的操作。
· View：定义了数据的展示，并负责接收用户输入。
· Controller：定义了对用户操作的响应。作为 Model 和 View 的连接，处理用户操作和数据上的改变。
MVC 模式的发明大大降低了前端数据和事件的管理难度。
MVC 模式的局限性在于所有事件都在 Controller 中处理，使得其比较臃肿。并且 View 和 Controller 的绑定过于紧密，不利于代码复用。
2. MVP (Model-View-Presenter)
在 MVP 模式中，View 和 Model 不能直接通信，必须通过 Presenter 来更新数据。这样，View 和 Model 就解耦了，可以作为单纯的展示层而存在。
MVP 模式由于需要做大量的数据同步工作，Presenter 也会和 View 绑定过于紧密。
3. MVVM (Model-View-ViewModel)
MVVM 由微软提出，用 ViewModel 的概念接管了 Presenter 的数据同步工作，这样省去了很多在 Presenter 里面的模版代码，架构和代码逻辑更加清晰。
4. MVVM-C (Model-View-ViewModel-Coordinator)
虽然 MVVM 省去了数据绑定的模版代码，但其在架构分层上只是用 ViewModel 取代了 Presenter，所以在实现时还是会有大量逻辑的堆砌，这常常被称为“垃圾抽屉”。并且 ViewModel 通常也不能在多个 View 间重用。这时我们可以加入一个 Coordinator 来协调 ViewModel 之间的跳转，来提高其复用性。
5. VIPER (View-Interactor-Presenter-Entity-Router)
VIPER 架构并不是基于 MVC 的改进，它是全新的架构模式，也是架构职责划分最明确的。然而其复杂度也是最大的，不适合较小规模的项目。
· View：定义了数据的展示，并负责接收用户输入。
· Entity：定义数据对象，但是不包括对数据访问和操作。
· Interactor：负责从 Entity 获取数据，执行数据操作逻辑。这里的数据结构独立于界面显示。
· Presenter：从 Interactor 获取数据，展示给用户。
· Router：负责模块间的跳转。
总体看来，每种模式都需要处理以下 3 个问题：
1. 数据源：一般从后端服务和存储中获得，其数据模型接近于后端。
2. 数据绑定：将一个或多个数据源整形处理为符合前端展示需要的数据，其数据模型可以一步到位接近前端模型，或者可以是一个中间状态方便页面间复用。
3. 事件响应：响应用户的操作，并对数据进行操作。
各个模式根据具体需求采用了不同的分层和解耦。我们需要根据需求来选取合适的架构模式。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
