Controller Builder

Dependency injection in controllers uses dataclasses to define and inject use case functions. Define a dependencies dataclass containing your use case functions, pass it to the controller constructor, and expose public methods that delegate to those injected use cases. This keeps business logic separate from your API layer.

Controllers should act as thin public interfaces that orchestrate use cases without containing business logic. Use a factory method like `create_default_controller` to instantiate controllers with all dependencies pre-configured, keeping your controller responsibilities focused on request routing and response formatting.

A `create_default_controller` factory method instantiates your controller with all required dependencies pre-injected. Use functools.partial to curry use case functions into the dependencies dataclass, then pass it to the controller. This pattern centralizes dependency configuration and simplifies testing.

Yes. Dataclasses define your dependency container with typed fields for each use case. Use functools.partial to pre-configure use case functions with their dependencies, store the partial functions in dataclass fields, and pass the dataclass instance to your controller for clean, type-hinted dependency access.

Keeping business logic in dedicated use case functions makes controllers testable, reusable across different interfaces, and easier to maintain. Controllers become thin orchestration layers that route requests to use cases and format responses, improving code organization and scalability.

Yes. Runtime validation ensures all dependencies are initialized before the controller executes, catching configuration errors early. Validate that required use case functions and repositories are present in your dependency container at controller instantiation or first method call.