数据访问层（DAL）与Repository模式

描述
数据访问层（Data Access Layer, DAL）是后端架构中负责与数据源（如数据库、缓存、外部API）交互的组件，其核心目标是将业务逻辑与数据存储技术解耦。Repository模式是实现DAL的一种常见设计模式，它通过提供集合式的接口（如Add、GetById、Find）封装底层数据操作，使业务层无需关心数据如何存储或查询。

为什么需要数据访问层？

1. 分离关注点：业务逻辑不应直接处理SQL或缓存细节。
2. 可测试性：业务层可通过Mock数据访问层进行单元测试。
3. 可维护性：更换数据库（如从MySQL迁移到PostgreSQL）只需修改DAL，不影响业务代码。

循序渐进理解实现过程

步骤1：分析没有DAL的典型问题

假设业务层直接嵌入SQL查询：

# 业务逻辑代码（问题示例）  
def get_user_orders(user_id):  
    # 直接混入SQL  
    conn = mysql.connect()  
    cursor = conn.cursor()  
    cursor.execute("SELECT * FROM orders WHERE user_id = %s", (user_id,))  
    orders = cursor.fetchall()  
    # 业务逻辑（如计算总金额）  
    total_amount = sum(order['amount'] for order in orders)  
    return total_amount  

问题：

• 业务逻辑与数据库耦合，难以测试（需真实数据库）。
• 重复的SQL代码散落在各处。

步骤2：基础数据访问层（DAL）的实现

将数据操作封装到独立的类中：

# 基础DAL类  
class OrderDAL:  
    def __init__(self, db_connection):  
        self.db = db_connection  

    def get_orders_by_user_id(self, user_id):  
        cursor = self.db.cursor()  
        cursor.execute("SELECT * FROM orders WHERE user_id = %s", (user_id,))  
        return cursor.fetchall()  

# 业务层使用DAL  
def get_user_orders(user_id, order_dal):  
    orders = order_dal.get_orders_by_user_id(user_id)  
    total_amount = sum(order['amount'] for order in orders)  
    return total_amount  

改进点：

• 业务逻辑不再直接依赖SQL，但仍依赖OrderDAL类（具体实现）。

步骤3：引入Repository模式抽象接口

定义抽象的Repository接口，解除业务层对具体DAL的依赖：

from abc import ABC, abstractmethod  

class OrderRepository(ABC):  
    @abstractmethod  
    def get_orders_by_user_id(self, user_id):  
        pass  

# 实现基于MySQL的Repository  
class MySQLOrderRepository(OrderRepository):  
    def __init__(self, db_connection):  
        self.dal = OrderDAL(db_connection)  # 复用基础DAL  

    def get_orders_by_user_id(self, user_id):  
        return self.dal.get_orders_by_user_id(user_id)  

# 业务层仅依赖抽象接口  
def get_user_orders(user_id, order_repo: OrderRepository):  
    orders = order_repo.get_orders_by_user_id(user_id)  
    total_amount = sum(order['amount'] for order in orders)  
    return total_amount  

关键优势：

• 业务代码依赖接口（OrderRepository），而非具体数据库实现。
• 可轻松切换数据源（如增加RedisOrderRepository）。

步骤4：泛型Repository与通用操作

为避免为每个实体（如User、Order）重复编写基础CRUD方法，可引入泛型Repository：

class GenericRepository(ABC):  
    @abstractmethod  
    def get_by_id(self, entity_id):  
        pass  

    @abstractmethod  
    def add(self, entity):  
        pass  

# 针对Order实体的特化Repository  
class OrderRepository(GenericRepository):  
    def get_orders_by_user_id(self, user_id):  
        # 特殊查询方法  
        pass  

注意：

• 通用操作（如CRUD）通过泛型接口统一，特殊查询在具体Repository中扩展。

步骤5：集成ORM（如SQLAlchemy、Hibernate）

现代DAL常基于ORM实现，Repository封装ORM操作：

# 使用SQLAlchemy示例  
class SQLAlchemyOrderRepository(OrderRepository):  
    def __init__(self, session):  
        self.session = session  # ORM会话  

    def get_orders_by_user_id(self, user_id):  
        return self.session.query(Order).filter(Order.user_id == user_id).all()  

    def add(self, order):  
        self.session.add(order)  

ORM的作用：

• 将数据库表映射为对象，减少手写SQL。
• Repository模式隐藏ORM细节，避免业务层直接操作ORM。

总结

• DAL是数据操作的抽象层，Repository是其在面向对象中的实现模式。
• 核心价值：通过接口隔离数据存储细节，提升代码可测试性和可维护性。
• 实践建议：结合ORM使用，但通过Repository限制业务层直接访问ORM，防止业务代码被ORM技术绑定。