A Controller Only Checks What It Can See Immediately
Why a controller should never hold business logic or touch a database directly, and the exact line between a structural check and a real validation.
A controller's whole job is taking a request and handing it to a service. It should never carry business logic of its own.
The Waiter Analogy: A Basic Check, Nothing Deeper
Ask a restaurant's waiter whether noodles are available, and they can answer immediately: yes, or no, we're out. What they can't do is walk to the kitchen, check every ingredient, and calculate a price on the spot — that's the kitchen's job, not the person taking the order.
A controller plays the exact same role. It can only check what's immediately visible on the request itself, nothing that requires reaching into a database or running real business rules.
Structural Checks Belong Here. Real Validation Doesn't.
A controller can check that a required field exists, that a value falls in a sane range, that a parameter isn't null. Confirming a user ID field is actually present is fair game.
What a controller can never do is confirm that value is correct, like checking whether that user ID belongs to a real, existing user. That check needs a database lookup, and a controller should never talk to a database directly. That work belongs entirely in the service, the only layer allowed to hold real business logic at all.
Keep reading