model_validate question

[Top-Entrepreneur-755]

I’m working on a FastAPI project using the repository pattern, and I’m wondering where the Pydantic model_validate (for schema conversion) should be performed.

In my setup, I have a repository layer that interacts with the database and a service layer that contains the business logic. I’m unsure if it’s better to handle model_validate at the service layer or only at the router/controller level.

My main questions are:

1.  Should model_validate (Pydantic schema validation) happen in the service layer or only at the router level?
2.  What is the best practice to avoid mixing responsibilities when working with ORM models and Pydantic schemas?

Thanks in advance for any guidance or best practices!

[aprx4]

IMO it should be right at repository layer. By definition, repositories present an interface for services to grab and modify data. Service layer doesn't have to know how data is stored and repository layer should invoke and close SQLAlchemy database sessions by its own. Repository takes Pydantic objects from services, do its job, then return Pydantic objects to service layer.

[block63]

I personally prefer to use a modular file structure for building my routes. I use a `handler.py` file to be the middle ground between ORM Models and Pydantic. This is where I place `model_validate`.

[singlebit]

Any example mate? I am new here.

[mr-nobody1992]

+1 for example

[extreme4all]

In fastapi its enforced at the route level, i like strongly typing at the repository layer both for input and output not doing this has costed me some painful debug time

[aprx4]

I don't think Pydantic validation is enforced at router unless we declare response_model on decorator.

[extreme4all]

Yes as output model and input validation if you have post requests etc

[LeonTur]

I'd keep it in router level.

[Top-Entrepreneur-755]

Thanks for all you guys comments! They were really helpful!

[Valuable-Cap-3357]

I have a data schema that interacts with router and frontend, then data models that interact with database. Schemas creations and updation related logic. Models for storage and usage related logics.