在数据/仓储层获取用户/租户ID是否属于不良开发实践？

是否违反SoC原则？ #

只要你做了抽象层隔离，就完全不违反关注分离（SoC）原则，反而符合依赖倒置的架构规范。
你的出发点非常合理：避免数据层依赖上层服务的具体实现，这个思路是分层架构的核心要求之一。你目前采用的Data <- Services <- Website依赖流向是完全正确的，只要避免直接把上层的具体实现类注入到数据层即可。

什么情况属于不良实践？ #

只有当你直接将Microsoft Identity的具体实现类（比如ClaimsPrincipal、SignInManager等属于Web层/Identity层的类型）直接注入到数据层时，才属于不良实践，会带来两个核心问题：

• 数据层和AspNetCore框架强绑定，后续如果需要把数据层复用到非Web场景（比如后台任务服务、桌面端工具）时，会因为缺少Identity运行环境完全无法运行
• 单元测试成本极高，测试数据层逻辑时需要额外模拟整个HttpContext和Identity上下文，没必要增加额外复杂度

符合架构规范的实现方案 #

按照你现有的分层架构，只需要补充一层抽象即可完美解决问题：

1. 在Data层定义抽象接口，只暴露数据层需要的最小能力，完全不依赖任何上层组件：

// 定义在Data项目中
public interface ICurrentUserAccessor
{
    // 只保留数据层需要的用户ID方法，不需要多余的属性/方法
    Guid? GetCurrentUserId();
}

2. 在Website层实现这个接口，这里才可以依赖Microsoft Identity相关的组件：

// 定义在Website项目中
public class IdentityCurrentUserAccessor : ICurrentUserAccessor
{
    private readonly IHttpContextAccessor _httpContextAccessor;

    public IdentityCurrentUserAccessor(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }

    public Guid? GetCurrentUserId()
    {
        var userIdClaim = _httpContextAccessor.HttpContext?.User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
        return Guid.TryParse(userIdClaim, out var userId) ? userId : null;
    }
}

3. 在Website层的DI容器中注册依赖：

builder.Services.AddScoped<ICurrentUserAccessor, IdentityCurrentUserAccessor>();

4. 数据层中只依赖你自己定义的ICurrentUserAccessor接口即可，不需要关心上层的实现逻辑。

这种实现方式下，数据层的关注点仍然是数据操作，获取当前用户ID只是数据层完成业务（比如行级权限过滤、操作审计字段自动赋值）的必要依赖，所有和Identity相关的实现逻辑都在上层，完全符合SoC的要求，也没有出现下层依赖上层的反向依赖问题。

额外优化建议 #

• 如果需要做数据层的单元测试，直接MockICurrentUserAccessor接口即可，不需要搭建任何Web运行环境
• 如果后续要调整用户标识的获取逻辑（比如切换成其他身份认证方案、支持多租户），只需要修改Website层的实现类，不需要改动任何Data层和Services层的代码

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