F#函数式范式下依赖管理、组合根实现及多层依赖传递问题求解

你当前的实现方向完全正确 #

你基于CompositionRoot封装I/O操作、纯逻辑只接收值的实现已经符合依赖拒绝理念的核心设计原则，和C#传统OO DI的本质差异在于：你注入的是工作流所需的最小能力集（可组合函数），而非完整的接口实现，不会出现注入大量当前场景不需要的方法的冗余问题，这个设计是符合函数式设计思路的。

如何避免依赖逐层透传 #

不需要手动把所有依赖从顶层逐层传递到底层，你可以利用F#的部分应用特性提前绑定依赖：

// 组合根阶段提前把依赖绑定到函数上，得到仅需业务参数的新函数
let boundFunction2 = function2 dependency2
let boundFunction1 = function1 dependency1 boundFunction2

// 顶层调用时只需要传入业务参数即可，不需要再传递依赖
let function0 boundFunction1 function0Input =
    let function1Input = ...
    boundFunction1 function1Input

通过这种方式，依赖只会在组合根阶段完成绑定，业务逻辑层的函数完全不需要感知依赖的存在，不会出现参数列表爆炸的问题。

手动管理依赖不会失控的方案 #

你不需要完全抛弃.NET自带的DI容器，可以将其作为底层依赖实例的托管工具，解决连接字符串等配置读取的问题：

• 把EF仓储、配置实例、日志实例这类底层基础设施直接注册到.NET DI容器中，仓储的连接字符串直接通过DI注入的IConfiguration读取，不需要硬编码
• 将你的CompositionRoot也注册到DI容器中，容器会自动把依赖的仓储实例注入到组合根的构造函数中
• 工作流需要的能力函数全部从组合根获取，不需要直接和DI容器交互，保证业务逻辑层完全和DI框架解耦

组合根的分层设计 #

建议采用两级组合根的设计，兼顾全局管理和场景隔离：

1. 全局组合根：放在程序入口处（和C#的Program.cs/Startup的DI注册位置一致），负责托管所有基础设施层的实例，封装所有I/O操作对应的原生函数
2. 工作流级组合根：每个独立业务工作流定义自己专属的能力结构体，结构体仅包含当前工作流需要用到的函数，从全局组合根中提取对应函数绑定好后生成工作流专属的能力实例。这种设计既避免了全局组合根过度臃肿，也保证了每个工作流只能拿到自己需要的依赖，不会出现权限溢出的问题。

内容的提问来源于stack exchange，提问作者Bremewoord