C#中多类多函数共享变量的常见访问方式及选型疑问

1. 直接传递变量给类/函数（依赖传递） #

这是最推荐的基础做法，尤其贴合单一职责和依赖倒置原则。

• 适用场景：变量仅在特定调用链路中被需要，或者需要保证类/函数的独立性、可测试性。
• 示例代码：

// 需要使用变量的函数
public void ProcessOrder(Order order, User currentUser)
{
    // 用currentUser处理业务逻辑
}

// 调用方直接传参
var currentUser = GetCurrentUser();
ProcessOrder(order, currentUser);

• 优势：类/函数的依赖关系一目了然，单元测试时能轻松传入模拟值，避免隐式依赖带来的调试麻烦。

2. 通过共享持有类的实例访问（依赖注入思路） #

如果变量属于某个业务实体或服务类的核心状态，更优的做法是共享该类的同一个实例，而非每次创建新实例（无状态工具类除外）。

• 适用场景：变量是服务/实体的持久化状态，多个类需要访问同一状态，比如数据库上下文、全局配置服务。
• 示例代码：

// 持有变量的服务类
public class UserContext
{
    public User CurrentUser { get; set; }
}

// 通过构造函数注入共享实例
public class OrderProcessor
{
    private readonly UserContext _userContext;

    public OrderProcessor(UserContext userContext)
    {
        _userContext = userContext;
    }

    public void ProcessOrder(Order order)
    {
        // 访问共享实例中的CurrentUser
        var user = _userContext.CurrentUser;
    }
}

// 调用方复用同一个UserContext实例
var userContext = new UserContext { CurrentUser = GetCurrentUser() };
var processor = new OrderProcessor(userContext);
processor.ProcessOrder(order);

• 注意：通常会结合依赖注入框架（如Microsoft DI、Autofac）来管理实例的生命周期（单例、作用域等），避免手动管理实例的繁琐。

3. 静态类/静态变量（谨慎使用） #

这是另一种常见方式，但副作用明显，需谨慎选择：

• 适用场景：全局共享的常量、无状态的工具类配置，或者不需要考虑线程安全的全局状态（线程安全需手动实现）。
• 示例代码：

public static class AppGlobals
{
    // 建议用readonly保证不可修改，避免意外篡改
    public static readonly User SystemUser = new User { Id = 0, Name = "System" };
}

// 直接访问静态变量
public void LogAction(string action)
{
    Console.WriteLine($"操作人：{AppGlobals.SystemUser.Name}，内容：{action}");
}

• 劣势：静态变量会导致类之间强耦合，单元测试难以隔离，多线程环境下容易出现并发问题。

总结选择原则 #

• 优先用直接传参：当变量是某个操作的临时输入，或者需要保证类的独立性时。
• 优先用共享实例访问：当变量是服务/实体的状态，且多个类需要访问同一状态时，结合依赖注入管理实例生命周期。
• 尽量避免静态变量：除非是全局常量或无状态配置，否则会带来耦合和测试难题。

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