📚 课程目录第4章分层架构

4、分层架构：表现层、业务逻辑层、数据访问层的职责划分与交互方式

分层架构是Python项目中最经典、应用最广泛的架构模式之一。它将系统按照职责划分为表现层（Presentation Layer）、业务逻辑层（Business Logic Layer）和数据访问层（Data Access Layer），通过明确的职责边界和依赖方向，实现“高内聚、低耦合”的设计目标。对于Python开发者而言，无论是构建Web应用（如Django、Flask、FastAPI）、命令行工具，还是数据处理服务，理解并正确实施分层架构，都是保障项目可维护性、可测试性和可扩展性的关键能力。本章将深入剖析三层的职责边界、交互规则、判断方法，并结合实际案例拆解分层落地的完整过程。

4.1 核心原理：三层职责的本质边界

分层架构的核心思想是“关注点分离”。每一层只解决特定类型的问题，并通过接口与相邻层通信。理解三层的本质边界，是正确实施分层的前提。

表现层（Presentation Layer）是系统与用户交互的窗口。它负责接收用户输入、展示处理结果，但不包含任何业务判断。在Python Web项目中，表现层通常由路由（Route）、视图函数（View）或控制器（Controller）组成。它的核心职责包括：解析HTTP请求参数（如查询字符串、JSON请求体）、调用业务逻辑层获取结果、将结果渲染为HTML模板或JSON响应、处理用户会话与认证状态。表现层应当保持“薄”的状态——它只做数据格式转换和流程转发，不编写业务规则。

业务逻辑层（Business Logic Layer）是系统的核心引擎，承载所有业务规则和流程编排。它接收表现层传递的已格式化数据，执行校验、计算、状态变更等操作，并决定调用哪些数据访问接口。业务逻辑层不关心数据最终存储在哪里（MySQL、PostgreSQL还是Redis），也不关心用户是通过浏览器还是API客户端访问。在Python项目中，业务逻辑层通常体现为Service类、领域服务或用例（Use Case）对象。例如，在电商系统中，“创建订单”的业务逻辑包括：校验库存、计算总价、生成订单号、扣减库存、记录日志——这些操作全部在业务逻辑层完成，表现层只负责将订单数据传给业务层并接收创建结果。

数据访问层（Data Access Layer）负责与持久化存储交互，执行数据的增删改查操作。它封装了数据库连接、SQL语句或ORM操作，向上层提供简洁的数据操作接口。数据访问层不包含业务判断，例如“库存是否充足”属于业务逻辑，而“查询商品库存数量”则属于数据访问。在Python中，数据访问层可以是SQLAlchemy的Repository模式、Django的Manager方法，或者直接使用数据库驱动执行原生SQL。数据访问层的核心价值在于隔离数据库细节——当数据库从MySQL迁移到PostgreSQL时，只需修改数据访问层，业务逻辑层和表现层不受影响。

三层依赖规则：表现层依赖业务逻辑层，业务逻辑层依赖数据访问层。依赖方向是单向的、自上而下的。反向只能返回数据结果，不能反向调用。禁止表现层直接访问数据访问层，也禁止业务逻辑层直接操作HTTP请求对象。

4.2 判断方法：如何划分职责与识别越层

在实际开发中，开发者经常面临“这段代码该放哪一层”的困惑。以下提供一套可操作的判断流程和检查清单，帮助准确划分职责。

判断流程：当编写一段代码时，依次回答以下问题：

这段代码是否涉及用户输入解析或输出格式化？如果是，属于表现层。例如：从request.json中提取字段、将datetime对象转为ISO格式字符串。
这段代码是否包含业务规则、条件判断或流程编排？如果是，属于业务逻辑层。例如：判断用户是否有权限执行操作、计算折扣价格、协调多个数据操作完成一个业务动作。
这段代码是否直接操作数据库、缓存或外部存储？如果是，属于数据访问层。例如：执行SELECT查询、写入Redis缓存、调用第三方API获取数据。

越层识别清单：以下现象表明分层被破坏，需要重构：

视图函数中出现SQL语句或ORM查询（表现层越权访问数据层）。
Service方法中直接使用request对象或session（业务逻辑层依赖表现层）。
数据访问层方法中包含if-else业务判断（数据层混入业务逻辑）。
表现层直接调用多个数据访问方法并自行组合结果（绕过业务逻辑层）。

代码片段	所属层次	判断依据
`request.args.get('page')`	表现层	解析HTTP请求参数
`if user.role == 'admin':`	业务逻辑层	权限判断属于业务规则
`session.query(Product).filter_by(id=pid)`	数据访问层	ORM查询操作
`return jsonify({'code': 200})`	表现层	响应格式化
`with db.transaction():`	业务逻辑层	事务管理属于业务编排

4.3 案例拆解：订单查询功能的正确分层实现

以一个典型的“订单详情查询”功能为例，展示三层如何协作。假设我们使用Flask + SQLAlchemy构建一个电商后端，需求是：用户通过订单ID查询订单详情，要求返回订单基本信息、商品列表和总金额，且只有订单所属用户本人或管理员可以查看。

初始目标与约束：接口为GET /api/orders/<order_id>，需要校验用户身份，返回JSON格式的订单数据。约束条件包括：订单数据分散在orders、order_items、products三张表中；权限规则为“本人或管理员可查看”；响应中金额字段需保留两位小数。

错误的分层实现（反面示例）：将所有逻辑写在视图函数中，直接操作数据库并包含权限判断：

@app.route('/api/orders/<int:order_id>')
def get_order(order_id):
    # 表现层直接操作数据库
    order = db.session.query(Order).get(order_id)
    if not order:
        return jsonify({'error': 'not found'}), 404
    # 业务判断混在表现层
    if request.user.id != order.user_id and request.user.role != 'admin':
        return jsonify({'error': 'forbidden'}), 403
    items = db.session.query(OrderItem).filter_by(order_id=order.id).all()
    # 数据组装逻辑也写在表现层
    result = {
        'id': order.id,
        'total': round(sum(i.price * i.quantity for i in items), 2),
        'items': [{'name': i.product.name, 'qty': i.quantity} for i in items]
    }
    return jsonify(result)

这段代码虽然功能正确，但存在严重问题：视图函数臃肿、无法单元测试业务逻辑、数据库迁移时需修改视图代码、权限规则无法复用。

正确的分层实现：按照三层架构重构，每层职责清晰：

第一步——数据访问层（Repository模式）：

class OrderRepository:
    def __init__(self, session):
        self.session = session

    def find_by_id(self, order_id):
        return self.session.query(Order).get(order_id)

    def find_items_with_product(self, order_id):
        return (self.session.query(OrderItem)
                .join(Product)
                .filter(OrderItem.order_id == order_id)
                .all())

第二步——业务逻辑层（OrderService）：

class OrderService:
    def __init__(self, repo: OrderRepository):
        self.repo = repo

    def get_order_detail(self, order_id, current_user):
        order = self.repo.find_by_id(order_id)
        if not order:
            raise OrderNotFoundError(order_id)
        if not self._can_view(order, current_user):
            raise PermissionDeniedError('无权查看该订单')
        items = self.repo.find_items_with_product(order_id)
        return self._build_detail(order, items)

    def _can_view(self, order, user):
        return order.user_id == user.id or user.role == 'admin'

    def _build_detail(self, order, items):
        total = round(sum(i.price * i.quantity for i in items), 2)
        return {
            'id': order.id,
            'total': total,
            'items': [{'name': i.product.name, 'qty': i.quantity} for i in items]
        }

第三步——表现层（视图函数）：

@app.route('/api/orders/<int:order_id>')
def get_order(order_id):
    service = OrderService(OrderRepository(db.session))
    try:
        data = service.get_order_detail(order_id, request.user)
        return jsonify(data)
    except OrderNotFoundError:
        return jsonify({'error': 'not found'}), 404
    except PermissionDeniedError:
        return jsonify({'error': 'forbidden'}), 403

结果对比与复盘：重构后，视图函数仅剩12行，只负责参数传递和异常响应；业务逻辑层可独立进行单元测试（无需启动Web服务器）；数据访问层可替换为其他数据库实现而不影响上层。代价是增加了类文件数量，但换来的是清晰的可维护性。在真实项目中，这种分层方式使得团队可以并行开发——前端工程师关注表现层，后端工程师专注业务逻辑，DBA优化数据访问层。

4.4 常见误区与总结复盘

在实施分层架构时，开发者常陷入以下误区，需要特别警惕：

误区一：过度分层导致“贫血模型”。有些团队将业务逻辑层变成纯粹的“数据搬运工”，所有判断都写在数据访问层或表现层，导致业务逻辑层形同虚设。正确的做法是：业务逻辑层应当包含核心业务规则，即使这些规则只有一行if判断。

误区二：表现层直接使用ORM对象。将SQLAlchemy模型直接序列化为JSON返回给前端，虽然开发速度快，但会暴露内部字段、无法控制输出格式，且当模型变更时影响API兼容性。应当在业务逻辑层组装DTO（数据传输对象）。

误区三：数据访问层包含业务判断。例如在Repository方法中写“如果订单状态为已取消则不返回”，这属于业务规则，应上移到业务逻辑层。数据访问层只做“查询订单”这一动作，是否过滤由上层决定。

误区四：忽略依赖注入。在Service中直接实例化Repository（如self.repo = OrderRepository()），导致难以替换为Mock对象进行测试。应当通过构造函数注入依赖，如OrderService(repo)。

总结复盘：分层架构的核心价值在于“隔离变化”——当技术栈调整（如从Flask切换到FastAPI）、数据库更换（从MySQL到PostgreSQL）、或业务规则变更时，影响范围被限制在特定层内。判断分层是否合理的标准是：如果修改一个需求，需要同时改动三层代码，说明职责划分不清晰；如果修改数据库字段，表现层和业务逻辑层完全不需要改动，说明数据访问层隔离做得好。在实际项目中，建议从“薄表现层、厚业务层、瘦数据层”开始，随着业务复杂度提升，再引入更细粒度的子层（如缓存层、消息队列层），但始终保持依赖方向自上而下。

分层架构不是银弹，对于简单的CRUD脚本或一次性数据处理任务，过度分层反而增加复杂度。但对于需要长期维护、多人协作、持续迭代的Python项目，分层架构是保障代码质量的基础设施。掌握三层的职责边界和交互方式，是Python工程师从“能写代码”进阶到“能设计系统”的关键一步。