仓储类中非CRUD操作的处理：销售专员统计数据返回方案咨询

首先得给你点个赞——你意识到把这些统计属性塞进SalesPerson是糟糕设计的直觉完全正确！往核心实体里硬塞这类场景化的统计字段，不仅会让实体变得臃肿，还会违背单一职责原则（SalesPerson本来就该只代表销售专员的核心属性，不是统计容器），而且每次查询都加载不需要的字段也会浪费性能。

针对你这种需要快速处理大量非CRUD统计的场景，最实用的方案有两个，都是围绕「分离核心实体和场景化数据」来做的：

1. 创建专门的统计DTO（数据传输对象） #

直接新建一个只承载统计数据的类，比如SalesPersonPerformanceStats，把你需要的所有统计字段都放进去：

public class SalesPersonPerformanceStats
{
    public int SalesPersonId { get; set; }
    public int ThirtyDaySaleCount { get; set; }
    public int SixtyDaySaleCount { get; set; }
    public int NinetyDaySaleCount { get; set; }
    public int CustomerCount { get; set; }
}

然后在你的ISalesPersonRepository里新增对应的查询方法，或者如果不想污染原仓储接口，也可以单独加一个小接口：

public interface ISalesPersonRepository
{
    // 原有CRUD方法...
    SalesPersonPerformanceStats GetPerformanceStats(int salesPersonId);
}

// 实现类里写对应的查询逻辑，直接从数据库拉取统计数据，不用加载完整的SalesPerson实体
public class SalesPersonRepository : ISalesPersonRepository
{
    // 原有CRUD实现...
    public SalesPersonPerformanceStats GetPerformanceStats(int salesPersonId)
    {
        // 直接写统计查询，比如用EF的话就是分组、聚合计算后返回这个DTO
        return _dbContext.Sales
            .Where(s => s.SalesPersonId == salesPersonId)
            .GroupBy(s => s.SalesPersonId)
            .Select(g => new SalesPersonPerformanceStats
            {
                SalesPersonId = salesPersonId,
                ThirtyDaySaleCount = g.Count(s => s.SaleDate >= DateTime.Now.AddDays(-30)),
                SixtyDaySaleCount = g.Count(s => s.SaleDate >= DateTime.Now.AddDays(-60)),
                NinetyDaySaleCount = g.Count(s => s.SaleDate >= DateTime.Now.AddDays(-90)),
                CustomerCount = g.Select(s => s.CustomerId).Distinct().Count()
            })
            .FirstOrDefault();
    }
}

这种方式的好处是：

• 完全不改动原有的SalesPerson实体，避免破坏核心模型
• 只返回业务需要的统计数据，查询性能更优
• 统计逻辑和核心CRUD逻辑分离，代码更清晰

2. 拆分出专门的统计仓储 #

如果这类统计需求特别多，甚至可以把所有统计相关的方法单独放到一个ISalesPersonStatsRepository里，让每个仓储的职责更单一：

public interface ISalesPersonStatsRepository
{
    SalesPersonPerformanceStats GetPerformanceStats(int salesPersonId);
    // 其他统计方法，比如GetTopSalesPersonsByThirtyDaySales()之类的
}

public class SalesPersonStatsRepository : ISalesPersonStatsRepository
{
    private readonly DbContext _dbContext;

    public SalesPersonStatsRepository(DbContext dbContext)
    {
        _dbContext = dbContext;
    }

    // 实现统计方法...
}

这样做的话，原有的SalesPersonRepository只专注于核心CRUD，统计逻辑全部归到新的仓储里，代码结构更清晰，后续维护也更方便。

最后说下你提到的贫血对象问题——虽然领域驱动设计里的富领域对象是理想方向，但你当前的首要需求是快速处理大量非CRUD操作，上面的方案完全可以满足你的需求，而且不用对现有代码做大规模重构。等后续有时间再考虑把统计逻辑逐步迁移到领域服务里，让实体变得更丰满也不迟。

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