如何合理组织重载方法？解决服务方法重复代码问题

针对服务层方法重载导致代码重复的问题，这里提供几种实用的解决方案，可结合场景选择：

1. 提取公共逻辑到私有核心方法（最推荐） #

这是最直接且低复杂度的方案，把两个方法中完全一致的核心逻辑抽成私有方法，两个重载方法仅负责获取对应的DbContext，再调用核心方法执行业务逻辑。

示例代码：

public class YourService
{
    private readonly DbContext _context;
    private readonly IService _service;

    // 构造函数注入依赖
    public YourService(DbContext context, IService service)
    {
        _context = context;
        _service = service;
    }

    // 原单参数重载
    public Task SomeOperation(string name)
    {
        return SomeOperationCore(_context, name);
    }

    // 新增带连接字符串的重载
    public Task SomeOperation(string name, string conString)
    {
        var context = _service.CreateContext(conString);
        return SomeOperationCore(context, name);
    }

    // 私有核心逻辑方法，封装所有公共业务代码
    private async Task SomeOperationCore(DbContext context, string name)
    {
        var user = await context.Users.FirstOrDefaultAsync(...);
        var anotherUser = await context.Users.FirstOrDefaultAsync(...);
        // 其他公共业务逻辑
    }
}

优点：代码结构清晰，维护成本低，后续修改核心逻辑只需改一处，完全避免重复代码。

2. 可选参数+内部条件判断（适合差异极小的场景） #

如果两个方法的差异仅在于DbContext的获取方式，且后续不会扩展更多分支，可以用可选参数简化代码，在方法内部根据参数是否存在选择对应的上下文。

示例代码：

public async Task SomeOperation(string name, string conString = null)
{
    // 根据连接字符串是否为空选择上下文
    var context = conString != null ? _service.CreateContext(conString) : _context;
    
    var user = await context.Users.FirstOrDefaultAsync(...);
    var anotherUser = await context.Users.FirstOrDefaultAsync(...);
    // 其他公共业务逻辑
}

优点：代码量最少，调用方式灵活；缺点：如果后续业务逻辑差异变大，方法会变得臃肿，可读性下降。

3. 策略模式（适合需扩展的场景） #

如果未来可能出现更多获取DbContext的方式（比如不同的数据源、不同的配置），可以用策略模式解耦上下文创建逻辑和业务逻辑，让代码更具扩展性。

步骤1：定义上下文提供策略接口 #

public interface IContextProvider
{
    DbContext GetContext(string conString = null);
}

步骤2：实现不同的策略类 #

// 默认策略：使用注入的上下文
public class DefaultContextProvider : IContextProvider
{
    private readonly DbContext _context;
    public DefaultContextProvider(DbContext context) => _context = context;
    
    public DbContext GetContext(string conString = null) => _context;
}

// 连接字符串策略：根据传入的连接字符串创建上下文
public class ConStringContextProvider : IContextProvider
{
    private readonly IService _service;
    public ConStringContextProvider(IService service) => _service = service;
    
    public DbContext GetContext(string conString) => _service.CreateContext(conString);
}

步骤3：服务层中使用策略 #

public class YourService
{
    private readonly IContextProvider _defaultContextProvider;
    private readonly ConStringContextProvider _conStringContextProvider;

    public YourService(DbContext context, IService service)
    {
        _defaultContextProvider = new DefaultContextProvider(context);
        _conStringContextProvider = new ConStringContextProvider(service);
    }

    public Task SomeOperation(string name)
    {
        var context = _defaultContextProvider.GetContext();
        return SomeOperationCore(context, name);
    }

    public Task SomeOperation(string name, string conString)
    {
        var context = _conStringContextProvider.GetContext(conString);
        return SomeOperationCore(context, name);
    }

    private async Task SomeOperationCore(DbContext context, string name)
    {
        // 核心业务逻辑
    }
}

优点：解耦了上下文创建和业务逻辑，新增上下文获取方式只需添加新的策略类，符合开闭原则；缺点：增加了少量代码复杂度，适合中大型项目的长期维护。

内容的提问来源于stack exchange，提问作者Андрей