网站建设知名,营销型网站的建设与推广辅导记录,专业的网站建设费用,广州建立网站的公司在这篇文章中#xff0c;我们将对 Kotlin 多平台移动端的最佳架构进行深入探讨。在2023年#xff0c;作为 Android 开发者#xff0c;我们会倾向于采用 MVVM 架构#xff0c;因为它简单、灵活且易于测试。而作为 iOS 开发者#xff0c;我们可能会选择 MVC、Viper 等架构。… 在这篇文章中我们将对 Kotlin 多平台移动端的最佳架构进行深入探讨。在2023年作为 Android 开发者我们会倾向于采用 MVVM 架构因为它简单、灵活且易于测试。而作为 iOS 开发者我们可能会选择 MVC、Viper 等架构。在 Flutter 世界中BLoCBusiness logic components是非常流行的架构。
Kotlin 多平台提供了跨平台开发支持在 iOS、Android 或桌面应用中共享业务逻辑和表示逻辑。在这里我们将进一步讨论应该遵循哪种架构并寻找适合 KMM 的架构。
我们想要实现什么
在架构方面没有明确的矩阵来决定应该采用哪种架构。在 KMM 的世界里架构应该足够灵活能够适应对现有代码的新变更并在可测试性和可维护性方面支持多个平台。
简单性是成功架构的关键。我们将避免使用繁琐的代码追求简单性。 以下是一些关键要点
最大程度地共享代码无论是业务逻辑还是表示逻辑。最小化平台特定的代码。便于本地和共享逻辑之间的交流。灵活适应未来的修改。遵循 SOLID 原则。
BLoC 架构
BLoC 表示基于业务逻辑组件的架构在 Flutter 世界中非常流行。让我们将其分解成较小的部分并尝试理解其矩阵。
业务逻辑组件
在 BLoC 中业务逻辑组件是一个简单的组件负责处理业务逻辑。它涉及对事件的响应通过对事件的响应来修改状态的更改。为了理解这一点让我们创建一个简单的组件并尝试实现业务逻辑。
//GalleryComponent.kt
interface GalleryComponent {val model: Modelfun 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 架构
MVIModel-View-Intent架构使用意图将业务逻辑和表示逻辑分离。在 MVI 中意图用于与业务逻辑进行通信。 在此意图从视图接收模型通过对意图的响应进行更新。从底层来看MVI 的代价在于可能出现竞争条件因为解决由竞争条件引起的一些错误会非常复杂。
在大型代码库中维护大量的意图非常复杂。但我喜欢 MVI 的简洁性。在此我已经假设您熟悉 MVI因此我们将跳过示例继续进行下一步。
MVC 或 MVP 架构
MVCModel-View-Controller或 MVPModel View Presenter架构在底层具有相同的行为。在 MVC 或 MVP 中控制器或 Presenter 充当中介通过对来自视图的事件进行响应来对模型进行修改。毫无疑问MVC 或 MVP 通过使用某种交互器很好地将业务逻辑和表示逻辑分开。
但是它会使代码更加灵活以进行测试。但是与此同时它带来了接口的复杂性和视图与模型之间的紧密耦合。尤其是在大型代码库中维护大量的接口会非常复杂。同上我已经假设您熟悉这些内容因此我们将跳过示例继续进行下一步。
MVVM 架构
MVVMModel-View-ViewModel架构将业务逻辑和表示逻辑分开消除了各组件之间的紧密耦合。在 MVVM 中ViewModel 充当模型和视图之间的桥梁。它对视图没有任何了解也没有对视图的直接引用。
ViewModel 通过对来自视图的事件进行响应来修改模型。如果您是 Android 开发人员您将对 MVVM 非常熟悉。MVVM 提供了任何应用程序所需的成功架构矩阵。它带来了灵活性、可扩展性和可维护性的好处。但是同样在大型代码库中维护 ViewModel 内部的大量状态会非常困难。
哪种架构应该被采用
众所周知每种架构都有其优缺点。但最终我们需要得出结论选择应该遵循哪种架构。 为了解决这个冲突您应该考虑以下关键点这些点有助于根据您的需求选择架构。如果您问我我的意见我建议考虑 MVVM 架构因为它简单易懂。
架构是否足够灵活以适应未来的修改架构是否支持应用程序要求架构是否支持测试性和简洁性架构组件是否对读取开放但对外部修改封闭团队采用架构是否容易它是否是干净而纯粹的架构不依赖于第三方库
总结
在 Kotlin Multiplatform Mobile 中市场上有多种架构库用于解决 KMM 中存在的多种问题。在 2023 年Circuit 架构、BLoC 架构、Decompose 架构等都将推出当前存在着大量的架构库。但我们是否应该使用这些架构 一个架构不应该依赖于任何带来维护问题的架构库。
我宁愿考虑使用简单而干净的 MVVM 架构它可以轻松扩展并对未来的修改开放而不依赖于任何其他的 API 或库。
