在 Python 的 Web 开发领域，FastAPI 以其高性能和简洁易用的特点备受开发者青睐。然而，随着项目规模的扩大，代码结构的清晰与否直接影响到项目的可维护性、可扩展性和可测试性。今天，我们就来探讨如何使用 FastAPI 创建清晰的代码结构，让你的项目更加规范、易于管理。

一、Pydantic 模式：数据的精准卫士

在构建 FastAPI 应用时，数据的验证和类型定义至关重要。Pydantic 模式在这方面发挥着关键作用。我们以用户相关的数据处理为例，在schemas/user.py文件中定义UserResponse类：

python

from pydantic import BaseModel

class UserResponse(BaseModel):
    id: int
    name: str
    email: str

通过 Pydantic 定义数据模型，所有的数据都有了明确的类型，并且会自动进行验证。这意味着，我们再也不用在程序中费力地处理不可靠的字典数据结构，有效避免了因数据类型错误或缺失引发的各种问题。无论是接收客户端请求的数据，还是向客户端返回的响应数据，Pydantic 模式都能确保数据的准确性和一致性。

二、服务层：承载核心业务逻辑

将业务逻辑从路由中分离出来是构建清晰代码结构的重要原则。我们在services/user_service.py文件中定义UserService类，专门用于处理与用户相关的业务逻辑：

python

from fastapi import HTTPException
from schemas.user import UserResponse
from repositories.user_repo import UserRepository

class UserService:
    def __init__(self, user_repo: UserRepository):
        self.user_repo = user_repo

    def get_user_by_id(self, user_id: int) -> UserResponse:
        user = self.user_repo.get(user_id)
        if not user:
            raise HTTPException(status_code=404, detail="User not found")
        return user

在这个类中，我们定义了get_user_by_id方法，该方法接收用户 ID 作为参数，通过调用UserRepository获取用户信息。如果用户不存在，则抛出HTTPException异常。这样的设计使得业务逻辑集中在服务层，路由层只负责接收请求和返回响应，两者职责明确，代码结构更加清晰。当业务逻辑发生变化时，我们只需要在服务层进行修改，而不会影响到其他部分，大大提高了代码的可维护性。

三、仓储层：数据访问的桥梁

仓储层用于处理与数据库的交互操作，它为服务层提供数据访问的接口。在repositories/user_repo.py文件中定义UserRepository类：

python

from sqlalchemy.orm import Session
from models import User

class UserRepository:
    def __init__(self, db: Session):
        self.db = db

    def get(self, user_id: int):
        return self.db.query(User).filter(User.id == user_id).first()

在UserRepository类的get方法中，我们通过传入的数据库会话对象db，查询指定 ID 的用户信息。这样的设计使得数据库操作与业务逻辑分离，在进行单元测试时，我们可以很方便地替换仓储层的实现，使用模拟数据来测试服务层和路由层的功能。清晰的边界划分，让测试变得更加简单和高效。

通过以上三个层次的划分 ——Pydantic 模式用于数据验证和定义、服务层承载业务逻辑、仓储层负责数据访问，我们可以在 Python 中使用 FastAPI 构建出清晰、规范的代码结构。这种结构不仅提高了代码的可读性和可维护性，还增强了项目的可扩展性和可测试性。无论是开发小型应用还是大型项目，遵循这样的代码结构设计原则，都能让你的开发工作更加得心应手，项目的生命周期也会更加长久 。快来尝试在你的 FastAPI 项目中应用这些方法，打造属于你的优质代码吧！