Kotlin多平台最佳架构指南

Kotlin多平台最佳架构指南_第1张图片
在这篇文章中,我们将对 Kotlin 多平台移动端的最佳架构进行深入探讨。在2023年,作为 Android 开发者,我们会倾向于采用 MVVM 架构,因为它简单、灵活且易于测试。而作为 iOS 开发者,我们可能会选择 MVC、Viper 等架构。在 Flutter 世界中,BLoC(Business logic components)是非常流行的架构。

Kotlin 多平台提供了跨平台开发,支持在 iOS、Android 或桌面应用中共享业务逻辑和表示逻辑。在这里,我们将进一步讨论应该遵循哪种架构,并寻找适合 KMM 的架构。

我们想要实现什么?

在架构方面,没有明确的矩阵来决定应该采用哪种架构。在 KMM 的世界里,架构应该足够灵活,能够适应对现有代码的新变更,并在可测试性和可维护性方面支持多个平台。

简单性是成功架构的关键。我们将避免使用繁琐的代码,追求简单性。
以下是一些关键要点:

  • 最大程度地共享代码,无论是业务逻辑还是表示逻辑。
  • 最小化平台特定的代码。
  • 便于本地和共享逻辑之间的交流。
  • 灵活适应未来的修改。
  • 遵循 SOLID 原则。

BLoC 架构

BLoC 表示基于业务逻辑组件的架构,在 Flutter 世界中非常流行。让我们将其分解成较小的部分,并尝试理解其矩阵。

业务逻辑组件

在 BLoC 中,业务逻辑组件是一个简单的组件,负责处理业务逻辑。它涉及对事件的响应,通过对事件的响应来修改状态的更改。为了理解这一点,让我们创建一个简单的组件并尝试实现业务逻辑。

//GalleryComponent.kt
interface GalleryComponent {
   val model: Model

   fun onGalleryClick()
   fun onDeleteClick()
   
   data class Model(val isLoading: Boolean)
}
//GalleryFeature.kt
class GalleryFeature(): GalleryComponent {
   override val model: Model get() = Model()
   
   override fun onGalleryClick() {
       //handle click here
   }

   override fun onDeleteClick() {
       //handle click here
   }
}

这不是一个典型的 BLoC 架构,如果您仔细查看GalleryComponent.kt或这些类,会发现 BLoC 还涉及状态、事件和消费者组件等。

我们希望保持简单,不涉及在 Kotlin 多平台中可以轻松避免的其他组件。如果您熟悉 MVVM 架构,将 BLoC 架构中的 ViewModel 替换为组件,那么它与 MVVM 架构非常相似。
通过观察其可测试性、灵活性和简单性,BLoC 架构也适用于 KMM 的世界。

事实上,BLoC 在 KMM 中带来了使用挑战,因为大多数开发人员来自 Android 和 iOS 的世界。他们更喜欢在 MVVM 上工作,而不是采用新的 BLoC 模式,尽管其行为与 MVVM 类似。如果您想尝试 BLoC 模式,我建议您不要使用任何复杂的架构库,因为这样会很难维护整体架构。

MVI 架构

MVI(Model-View-Intent)架构使用意图将业务逻辑和表示逻辑分离。在 MVI 中,意图用于与业务逻辑进行通信。
在此,意图从视图接收,模型通过对意图的响应进行更新。从底层来看,MVI 的代价在于可能出现竞争条件,因为解决由竞争条件引起的一些错误会非常复杂。

在大型代码库中,维护大量的意图非常复杂。但我喜欢 MVI 的简洁性。在此,我已经假设您熟悉 MVI,因此我们将跳过示例,继续进行下一步。

MVC 或 MVP 架构

MVC(Model-View-Controller) MVP(Model View Presenter)架构在底层具有相同的行为。在 MVC 或 MVP 中,控制器或 Presenter 充当中介,通过对来自视图的事件进行响应来对模型进行修改。毫无疑问,MVC 或 MVP 通过使用某种交互器很好地将业务逻辑和表示逻辑分开。

但是它会使代码更加灵活以进行测试。但是,与此同时,它带来了接口的复杂性和视图与模型之间的紧密耦合。尤其是在大型代码库中,维护大量的接口会非常复杂。同上,我已经假设您熟悉这些内容,因此我们将跳过示例,继续进行下一步。

MVVM 架构

MVVM(Model-View-ViewModel)架构将业务逻辑和表示逻辑分开,消除了各组件之间的紧密耦合。在 MVVM 中,ViewModel 充当模型和视图之间的桥梁。它对视图没有任何了解,也没有对视图的直接引用。

ViewModel 通过对来自视图的事件进行响应来修改模型。如果您是 Android 开发人员,您将对 MVVM 非常熟悉。MVVM 提供了任何应用程序所需的成功架构矩阵。它带来了灵活性、可扩展性和可维护性的好处。但是,同样,在大型代码库中,维护 ViewModel 内部的大量状态会非常困难。

哪种架构应该被采用?

众所周知,每种架构都有其优缺点。但最终,我们需要得出结论,选择应该遵循哪种架构。
为了解决这个冲突,您应该考虑以下关键点,这些点有助于根据您的需求选择架构。如果您问我我的意见,我建议考虑 MVVM 架构,因为它简单易懂。

  • 架构是否足够灵活以适应未来的修改?
  • 架构是否支持应用程序要求?
  • 架构是否支持测试性和简洁性?
  • 架构组件是否对读取开放,但对外部修改封闭?
  • 团队采用架构是否容易?
  • 它是否是干净而纯粹的架构,不依赖于第三方库?

总结

在 Kotlin Multiplatform Mobile 中,市场上有多种架构库,用于解决 KMM 中存在的多种问题。在 2023 年,Circuit 架构、BLoC 架构、Decompose 架构等都将推出,当前存在着大量的架构库。但我们是否应该使用这些架构?
一个架构不应该依赖于任何带来维护问题的架构库。

我宁愿考虑使用简单而干净的 MVVM 架构,它可以轻松扩展,并对未来的修改开放,而不依赖于任何其他的 API 或库。

你可能感兴趣的:(kotlin多平台,kotlin,架构,开发语言)