小编点评

Vue3 已经非常强大和灵活了，但仍然引入了 IOC 容器，原因在于其可以解决一些 Vue2 中的痛点问题。 首先，Vue 官方不再推荐使用基于 Class 定义 Vue 组件的方式，主要是因为这种方式存在一些问题。例如，使用 Class 定义组件会导致组件之间的耦合性增加，使得组件的维护性和可重用性降低。此外，使用 Class 定义组件还可能导致命名冲突等问题。 然而，在业务层架构中，使用 Class 和 OOP 类型的 IOC 容器是有价值的。这是因为业务层需要处理复杂的业务逻辑和数据模型，而 OOP 提供了一种更加灵活和高效的方式来处理这些问题。通过在业务层中使用 Class 和 OOP 类型的 IOC 容器，可以实现更好的代码组织和管理，提高代码的可维护性和可读性。 具体来说，IOC 容器可以用于以下几个方面： 1. 全局状态和逻辑共享：通过将全局状态和逻辑放在一个 IOC 容器中，可以实现全局状态的统一管理和共享，避免不同组件之间直接访问造成的耦合性问题。 2. 组件实例共享：在组件实例中，可以通过 IOC 容器共享数据和方法等，方便不同组件之间的通信和协作。 3. 代码的组织和管理：通过将业务逻辑和数据模型封装在 Class 中，并使用 IOC 容器进行管理，可以提高代码的组织和管理效率，减少代码量和维护成本。 总之，虽然 Vue3 已经非常强大和灵活，但在业务层架构中，使用 Class 和 OOP 类型的 IOC 容器仍然是一种非常有用的技术手段，可以帮助开发者更好地处理复杂业务和数据模型。

正文

Vue3 已经非常强大和灵活了，为什么还要引入 IOC 容器呢？IOC 容器离不开 Class，那么我们就从 Class 谈起

Class的应用场景

一提起 Class，大家一定会想到这是 Vue 官方不再推荐的代码范式。其实，更确切的说，Vue 官方是不推荐基于 Class 来定义 Vue 组件。如图所示：

社区确实有几款基于Class定义组件的方案，但实际应用效果不理想，所以不被 Vue 官方推荐。这些有价值的社区实践在不同阶段给 Vue 开发带来了便利，同时也恰恰说明一个道理：

Class 不应该用在`视图层`，而是要用到`业务层`

• 以下是几款社区 Class 定义组件的方案，供参考：
  • vue-class-component
  • vue-facing-decorator
  • vue-property-decorator
  • nuxt-property-decorator

两层架构设计

在面向大型的业务开发场景中，需要两个层面的架构设计：

1. 视图层：这一层架构推荐使用<script setup>，因为通过编译器语法糖确实可以使用非常简明的代码来声明 props 和 emits 的类型
2. 业务层：这一层与业务相关。大量的工程实践证明，对于业务的建模和抽象，OOP比函数式更适合

因此，在 Vue3 中引入 IOC 容器和 Class，与 Vue 官方的说法并不相悖，只是在业务层架构中应用Class和OOP

两类IOC容器

Zova 提供了分层的 IOC 容器，具体而言，提供了两类 IOC 容器：

1. 全局容器

该容器与Vue App绑定，从而实现全局状态和逻辑的共享，因此可以直接代替pinia的能力

2. 组件实例容器

该容器与Vue组件实例绑定。提供组件实例级别容器的好处就是，在这个容器中的所有 Class 实例都可以在组件实例范围之内共享数据和逻辑

和 Mixins 的对比

下面是基于 IOC 容器的源码案例，可以与 Mixins 做对照分析：

• 布局组件

1. 解决mixins的短板

使用过 Vue2 的用户可能对mixins比较熟悉。IOC容器可以解决 mixins 的所有短板：

1. 不清晰的数据来源：在 IOC 中 Class 各司其职，可以很方便的对this溯源，定位其出处
2. 命名空间冲突：在 IOC 中 Class 实例都有自己的变量名，自然没有命名冲突的隐患
3. 隐式的跨 mixin 交流：通过 IOC 容器的托管，Class 实例可以非常方便的共享数据和逻辑，而且可以清晰定位其来源

• 参见：Vue3: 和 Mixin 的对比

2. 吸收mixins的长处

mixins虽然有许多短板，但是有一个长处，就是多个mixins之间共享数据和逻辑非常方便。组合式API虽然也能实现数据和逻辑的共享，但是一旦调用链层级深了，使用起来就不太方便

• 我们可以看一张示意图：

如图所示，一个 Vue 组件使用了两个 Composables，然后这两个 Composables 又分别使用了两个 Composables。那么，如果要在这 6 个 Composables 中共享状态和逻辑是非常不方便的，无法满足复杂业务的需求

• 我们再来看 IOC 容器的示意图：

如图所示，一个 Vue 组件对应一个 IOC 容器，在 IOC 容器中注入了 6 个 Class 实例。这些 Class 实例由于都被 IOC 容器托管，所以可以相互引用，从而方便共享状态和逻辑

额外好处

基于 Vue3 强大而且灵活的响应式系统，IOC 容器在创建 Class 实例时自动包裹一层 reactive，那么就可以收到如下好处：

1. 不用ref/reactive：有了 IOC 容器的加持，定义响应式状态不再需要ref/reactive
2. 不用ref.value：因为不用ref，自然也就不用再写大量的ref.value

概念辨析

有人说Zova中Java的味道很浓

其实，Zova 与 Java 的代码风格有显著的不同，体现在以下两个方面：

1. 更少的装饰器函数：Zova 采用依赖注入与依赖查找相结合的策略，优先使用依赖查找，从而大量减少装饰器函数的使用
2. 更少的类型标注：Zova 优先使用依赖查找可以达到化类型于无形的开发体验，也就是不需要标注类型就可以享受到类型编程的诸多好处，从而让我们的代码始终保持简洁和优雅，进而显著提升开发效率，保证代码质量

• 详细方案，参见：
  • IOC控制反转: BeanBase
  • 模块Scope

有人说前端的技术趋势是组合优于继承，所以引入IOC是不合时宜的

其实，从本质上来看，IOC 容器的核心架构理念就是组合。通过 IOC 容器的托管，这些 Bean 实例可以更加自由灵活的组合，可以更加便利的共享状态和逻辑

结语

那么，如果搬砖累了，就玩一玩支持ioc容器的vue3框架吧，尝试一下全新的开发体验。

Zova源码已开源，欢迎围观：https://github.com/cabloy/zova

Zova可以和任何UI库搭配使用，这里有一个daisyui的效果演示：https://zova.js.org/zova-demo/