嘿，这个问题我在不同规模的项目里都碰见过，两种方案各有适用场景，先给你掰扯清楚各自的好坏，再聊聊更平衡的实现方式。

一、每个查询对应一个方法（50+方法的类） #

优点 #

• 语义化极强：比如getUserByEmailAndStatus()这种方法名，一眼就能知道它做什么，业务层调用时完全不用关心SQL细节，新人接手成本极低。
• 统一逻辑复用：所有查询的通用逻辑（比如参数校验、SQL日志、结果集映射、缓存处理）都能集中在这些方法里，不用每个业务场景重复写。
• 降低出错概率：SQL都封装在数据访问层，避免业务层写错SQL，也能统一防护SQL注入（比如统一用预编译语句）。

缺点 #

• 类臃肿到爆炸：50个方法已经很难维护了，后续需求迭代只会让这个类越来越庞大，找个方法都要翻半天。
• 灵活性极差：遇到临时的复杂查询（比如多表关联+动态过滤条件），要么硬加一个新方法（进一步加剧臃肿），要么直接绕开这个类写裸SQL，破坏了封装性。
• 重复代码泛滥：很多方法只是WHERE条件不同，比如getUserById()、getUserByEmail()、getUserByPhone()，本质都是SELECT，但要写一堆相似的方法。

二、通用CRUD方法+业务层写SQL #

优点 #

• 极致精简：数据库类就几个方法（select(sql, params)、update(sql, params)等），维护成本几乎为0。
• 灵活性拉满：任何复杂查询都能直接写SQL实现，不用受限于预定义的方法，应对多变需求特别快。
• 避免方法爆炸：不会出现几十个相似的方法，不用为每一种查询场景新增方法。

缺点 #

• 业务与SQL强耦合：业务逻辑代码里混着大量SQL，可读性极差，后期改需求时要同时改业务逻辑和SQL，容易漏改。
• SQL重复问题：相同的查询逻辑可能在多个业务方法里重复写，后期要改SQL得找遍所有业务代码，维护成本飙升。
• 缺少统一管控：每个业务方法都要自己处理参数校验、日志、缓存等，容易遗漏，也会导致代码重复。
• 对开发者要求高：新人可能写出低效SQL，甚至不小心引入SQL注入风险，没有统一的防护机制。

三、更合适的折中实现方式 #

其实大多数项目都不需要走极端，以下几种方案能平衡封装性和灵活性：

1. 拆分Repository + 常用查询+ Query Builder #

• 按实体拆分Repository：把原来的大数据库类拆成多个小的Repository，比如UserRepository、OrderRepository，每个对应一个业务实体，每个Repository只负责该实体的数据库操作，避免单个类臃肿。
• 保留常用查询方法：把项目中高频使用的查询（比如getRecentOrdersByUserId()）封装成Repository的方法，保证语义化和复用性。
• 用Query Builder处理动态查询：对于复杂的动态查询（比如用户多条件筛选），用Query Builder让业务层可以灵活拼接条件，不用写裸SQL。

示例伪代码：

class UserRepository:
    # 通用CRUD
    def get_by_id(self, user_id):
        pass
    def save(self, user):
        pass
    
    # 常用查询
    def get_by_role(self, role):
        pass
    
    # Query Builder
    def query(self):
        return UserQueryBuilder()

class UserQueryBuilder:
    def __init__(self):
        self.conditions = []
    
    def name_like(self, name):
        self.conditions.append(f"name LIKE '%{name}%'")
        return self
    
    def age_greater_than(self, age):
        self.conditions.append(f"age > {age}")
        return self
    
    def list(self):
        # 拼接SQL并执行
        sql = "SELECT * FROM users WHERE " + " AND ".join(self.conditions)
        return self.execute(sql)

2. 轻量级ORM框架 #

直接用成熟的轻量级ORM框架（比如MyBatis、Dapper、SQLAlchemy），它们完美解决了手写数据库类的痛点：

• 自动生成简单CRUD，不用自己写重复代码；
• 支持自定义SQL，应对复杂查询；
• 自动处理参数绑定、结果集映射、SQL注入防护；
• 部分框架还支持动态SQL（比如MyBatis的<if>标签），不用自己拼接SQL。

这种方案几乎是大多数项目的最优解，既不用自己维护庞大的数据库类，又能保持SQL的灵活性。

3. Active Record模式 #

让实体类自己集成数据库操作能力，比如Ruby on Rails的ActiveRecord、Java的ActiveJDBC。每个实体类自带save()、find_by_id()、delete()等方法，同时支持链式查询：

示例伪代码：

# 查询年龄大于18的用户，按创建时间排序
User.where("age > ?", 18).order("created_at DESC").all

# 保存用户
user = User.new(name: "Alice", age: 20)
user.save

这种方式代码极其简洁，适合小型项目或快速迭代的场景，省去了单独写数据访问层的麻烦。

总结 #

• 如果你的项目查询场景固定、业务逻辑简单，且希望严格封装SQL，建议拆分多个Repository，避免单个类臃肿；
• 如果项目需求多变、经常有复杂动态查询，优先选轻量级ORM，或者通用CRUD+Query Builder的组合；
• 尽量避免让业务层直接写裸SQL，除非是极小的项目，否则后期维护成本会非常高。

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