关于用户头像存储逻辑及字段附加位置的技术咨询

1. 不将文件名存储到数据库中的做法是否正确？ #

这种做法是合理且可行的，但需结合业务场景判断利弊：

• 优势：

  • 消除冗余数据：头像文件名完全由用户ID推导而来，存储它只会占用不必要的数据库空间。
  • 避免数据不一致：若用户ID为不可变主键（通常都是如此），头像路径永远与用户信息匹配，无需担心文件名和ID脱节的问题。

• 潜在局限：

  • 灵活性不足：如果未来需要修改头像命名规则（比如添加哈希后缀、更换文件格式），你得修改所有生成头像路径的代码，而非直接更新数据库记录。
  • 缺失状态标记：若存在用户未上传头像的情况，你需要额外处理文件不存在的场景（比如返回默认头像），而数据库存储文件名可直接标记是否存在有效头像。

综上，若你的头像命名规则长期稳定，且所有用户都有对应的头像文件，这种做法完全没问题。

2. 附加avatar字段的逻辑应放在Repository还是Service中？ #

应该放在Service层，原因如下：

• Repository的核心职责是封装数据库操作，专注于读取/写入原始的UserModel数据，不应承担数据转换或业务逻辑的工作。
• Service层负责处理业务逻辑、数据组装和对外提供接口。将生成头像路径的逻辑放在这里，既符合单一职责原则，也方便后续调整路径规则时只需修改Service层代码。
• 伪代码示例：

  class UsersService {
    constructor(usersRepository) {
      this.usersRepository = usersRepository;
    }
  
    async getUserById(id) {
      const user = await this.usersRepository.findById(id);
      return {
        ...user,
        avatar: `/assets/usersAvatars/${user.id}.jpg`
      };
    }
  }
  

如果后续多个场景需要返回带avatar的用户数据，Service层的统一实现能避免重复代码，保证逻辑一致性。

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