无论是 iOS 还是 Android 开发,前端架构模式都是应用程序开发中最常用的模式之一。开发人员引入这些模式是为了克服早期模式的局限性。那么,它们有什么不同呢?又解决了什么问题呢?
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. 事件响应:响应用户的操作,并对数据进行操作。
各个模式根据具体需求采用了不同的分层和解耦。我们需要根据需求来选取合适的架构模式。
作者:李华