Service/Repository模式下C#/.NET8服务类方法取舍及最佳实践

核心原则：服务类应专注于业务流程编排与外部依赖协调，GetTeamName()、GetNextEventId()这类针对单个领域对象的属性提取/校验逻辑，不属于服务类核心职责，应剥离到更合适的载体中，同时满足可测试、带日志的需求。以下是几种可行方案：

方案1：封装到领域对象（优先推荐，若允许修改对象类） #

如果EspnBasketballTeam是你可控的领域类（而非第三方API返回的不可修改DTO），直接将逻辑作为实例方法封装到类内部，符合面向对象封装原则，数据与操作数据的行为绑定：

public class EspnBasketballTeam
{
    // 原有属性
    public TeamDetails? team { get; set; }

    public string GetTeamName(ILogger<EspnBasketballTeam>? logger = null)
    {
        try
        {
            if (team == null)
            {
                throw new InvalidOperationException("Team details are null.");
            }
            return team.name ?? string.Empty;
        }
        catch (Exception ex)
        {
            logger?.LogError(ex, "Failed to retrieve team name");
            return string.Empty;
        }
    }

    public string GetNextEventId(ILogger<EspnBasketballTeam>? logger = null)
    {
        try
        {
            if (team?.nextEvent == null || !team.nextEvent.Any())
            {
                throw new InvalidOperationException("No upcoming events found for the team.");
            }
            return team.nextEvent.First().id ?? string.Empty;
        }
        catch (Exception ex)
        {
            logger?.LogError(ex, "Failed to retrieve next event ID");
            return string.Empty;
        }
    }
}

// 服务类中的调用简化为：
public string GetTeamName(EspnBasketballTeam? team)
{
    return team?.GetTeamName(_logger) ?? string.Empty;
}

优势：职责清晰，符合OOP设计；测试时只需创建对象实例，传入Mock的ILogger即可验证日志输出和返回值。

方案2：专用对象处理器类（适合不可修改的DTO场景） #

如果EspnBasketballTeam是第三方API返回的自动生成DTO（无法修改），可创建专门的处理器类，注入日志依赖，专注于该对象的逻辑处理：

// 定义处理器接口
public interface IEspnBasketballTeamProcessor
{
    string GetTeamName(EspnBasketballTeam? team);
    string GetNextEventId(EspnBasketballTeam? team);
}

// 实现类
public class EspnBasketballTeamProcessor : IEspnBasketballTeamProcessor
{
    private readonly ILogger<EspnBasketballTeamProcessor> _logger;

    public EspnBasketballTeamProcessor(ILogger<EspnBasketballTeamProcessor> logger)
    {
        _logger = logger;
    }

    public string GetTeamName(EspnBasketballTeam? team)
    {
        try
        {
            if (team == null || team.team == null)
            {
                throw new InvalidOperationException("Team or team details are null.");
            }
            return team.team.name ?? string.Empty;
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Error getting team name");
            return string.Empty;
        }
    }

    public string GetNextEventId(EspnBasketballTeam? team)
    {
        try
        {
            if (team == null || team.team == null || team.team.nextEvent == null || !team.team.nextEvent.Any())
            {
                throw new InvalidOperationException("Team has no valid upcoming events.");
            }
            return team.team.nextEvent.First().id ?? string.Empty;
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Error getting next event ID");
            return string.Empty;
        }
    }
}

然后在服务类中注入该处理器：

public class EspnBasketballService : IEspnBasketballService
{
    private readonly ILogger<EspnBasketballService> _logger;
    private readonly IEspnBasketballRepository _espnRepo;
    private readonly IEspnBasketballTeamProcessor _teamProcessor;

    public EspnBasketballService(IEspnBasketballRepository espnRepo, ILogger<EspnBasketballService> logger, IEspnBasketballTeamProcessor teamProcessor)
    {
        _espnRepo = espnRepo;
        _logger = logger;
        _teamProcessor = teamProcessor;
    }

    public Task<EspnBasketballTeam?> GetBasketballTeam() => _espnRepo.GetBasketballTeam();

    public string GetTeamName(EspnBasketballTeam? team)
    {
        return _teamProcessor.GetTeamName(team);
    }

    public string GetNextEventId(EspnBasketballTeam? team)
    {
        return _teamProcessor.GetNextEventId(team);
    }
}

优势：职责单一，可独立测试；依赖注入日志，避免静态方法的弊端；符合SOLID原则，后续扩展逻辑只需修改处理器类。

方案3：扩展方法（适合纯无依赖逻辑，不推荐带日志场景） #

如果逻辑非常简单且无强日志需求，扩展方法是轻量选择，但因扩展方法为静态，无法直接注入日志（需手动传递，调用繁琐），仅推荐无日志需求的场景：

public static class EspnBasketballTeamExtensions
{
    public static string GetTeamName(this EspnBasketballTeam? team, ILogger? logger = null)
    {
        try
        {
            if (team?.team == null)
            {
                throw new InvalidOperationException("Team details missing.");
            }
            return team.team.name ?? string.Empty;
        }
        catch (Exception ex)
        {
            logger?.LogError(ex, "Failed to get team name");
            return string.Empty;
        }
    }

    // GetNextEventId 同理实现
}

// 服务类中调用：
public string GetTeamName(EspnBasketballTeam? team)
{
    return team.GetTeamName(_logger);
}

注意：静态方法测试相对麻烦，日志需手动传递，若后续逻辑复杂，维护成本会升高。

通用优化建议 #

• 避免抛出通用Exception，改用更具体的异常类型（如InvalidOperationException），提升调试效率；
• 日志中应包含异常完整信息（LogError(ex, "message")而非仅ex.Message），便于排查问题；
• 服务类保持精简，只做“协调工作”：调用仓库获取数据，调用处理器处理数据，不直接处理对象属性。

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