Python中如何优雅地编写后端接口逻辑？

对于后端接口最优雅的方式应该是:
1.按照单个业务区分 (如 处理一个文件, 直接用户上传到处理然后返回处理结果) 的方式

2.分为多个接口 (先上传文件, 再请求处理)的方式, 这样前端会产生多个请求

3.其他更好解决方式

能给我一点您们的经验吗?
Python中如何优雅地编写后端接口逻辑？

10 回复

我个人倾向低耦合，具体情况看需求


核心就是分层，别把路由、业务逻辑、数据访问全堆一块儿。

我习惯这么干，拿个 Flask 例子来说：

  1. 路由层 (app.py)：只负责接收请求、调用服务、返回响应。干净利落。

    from flask import Flask, request, jsonify
from services.user_service import UserService

app = Flask(__name__)
user_service = UserService()

@app.route('/api/user/<int:user_id>', methods=['GET'])
def get_user(user_id):
    user = user_service.get_user_by_id(user_id)
    if not user:
        return jsonify({'error': 'User not found'}), 404
    return jsonify(user.to_dict())

  2. 服务层 (services/user_service.py)：放核心业务逻辑。这里处理各种规则和流程。

    class UserService:
    def __init__(self):
        from repositories.user_repository import UserRepository
        self.repo = UserRepository()

    def get_user_by_id(self, user_id):
        # 这里可以加缓存、权限检查等业务逻辑
        return self.repo.find_by_id(user_id)

  3. 数据层 (repositories/user_repository.py)：只管和数据库打交道，别的不管。

    class UserRepository:
    def find_by_id(self, user_id):
        # 模拟数据库查询
        from models.user import User
        # ... 实际会执行 SQLAlchemy 查询或 SQL
        return User.query.get(user_id)  # 示例

  4. 模型层 (models/user.py)：定义数据结构，可以和 ORM 结合。

    class User:
    def __init__(self, id, name):
        self.id = id
        self.name = name

    def to_dict(self):
        return {'id': self.id, 'name': self.name}

总结：各司其职，一个函数只干一件事，改起来方便。

我推荐方式一.

低耦合不意味着接口要拆的很细,你可以在你后端代码内部做好封装来提高代码的高重用,而不是把复杂度扔给前端.
跨接口的事务等逻辑处理起来比单个接口要复杂很多的.

graphql 了解一下。

文件巨大难以上传
可以考虑 2

具体看需求。以后可能会存在用户对以前上传的文件进行处理的需求么？如果存在当然第二个合理






谢谢, 看来需求是最重要的. 文件是不大的. 一般的情况是逻辑相对不复杂我才会考虑放到一个接口的.

所有提供给别人用的东西，都要优先考虑使用者的感受，然后才是技术实现。
写个后端接口，我觉得首先是要想别人如果要调用这个接口，应该怎么写代码。
想清楚这个，就很容易判断该怎么做了。

1.文件上传单独一个接口，上传完成后文件信息保存到 redis 或 session 中并回传到页面
2.页面带文件信息访问对应业务接口，业务接口访问文件服务完成业务操作，返回业务数据

好处是文件接口不用每次新加一个需求就又要调一次，前端开发时上传文件只需要熟悉这一个接口并封装一下即可，后端开发对文件服务解耦和，日后更替时可随意切，很方便。

缺陷就是需要调两次接口，不过一般这个不会是瓶颈部分。

自己写前端一段时间就知道啦

回到顶部